summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* [Docs] Fix code formattign in variable.rstJonas Devlieghere2019-05-131-0/+1
| | | | | | Fixes missing newline between :: and the actual code. llvm-svn: 360632
* [CMake] Reinstate LLDB_CAN_USE_LLDB_SERVERJonas Devlieghere2019-05-132-3/+8
| | | | | | | | | | We cannot manipulate the LLDB_TOOL_LLDB_SERVER_BUILD directly from LLDBConfig.cmake because this would set the variable before the option is defined in AddLLVM.cmake. Instead, we need to use the LLDB_CAN_USE_LLDB_SERVER variable to conditionally add the lldb-server subdirectory. This should ensure the variable doesn't get cleared. llvm-svn: 360631
* Disable TestEnvironment on WindowsJonas Devlieghere2019-05-131-0/+2
| | | | | | | | | | | | | | The input source file seems to be triggering an error in the Visual Studio headers. > xstddef:338:2: error: ''auto' return without trailing return type; > deduced return types are a C++14 extension I tried converting the test to use the %build stuff Zachary added, but that seems to be missing some Darwin support. Disabling the test on Windows in the meantime. llvm-svn: 360624
* [CMake] Simplify lldb-server handlingJonas Devlieghere2019-05-133-18/+8
| | | | | | | | | We can piggyback off the existing add_lldb_tool_subdirectory to decide whether or not lldb-server should be built. Differential revision: https://reviews.llvm.org/D61872 llvm-svn: 360621
* Merge target and launch info environmentsJonas Devlieghere2019-05-133-1/+18
| | | | | | | | | | | Before this change we were overriding the launch info environment with the target environment. This meant that the environment variables passed to `process launch --environment <>` were lost. Instead of replacing the environment, we should merge them. Differential revision: https://reviews.llvm.org/D61864 llvm-svn: 360612
* Remove commented-out codeJonas Devlieghere2019-05-131-43/+0
| | | | llvm-svn: 360611
* [DataFormatters] FindLibCppStdFunctionCallableInfo() currently uses ↵Shafik Yaghmour2019-05-131-2/+2
| | | | | | | | FindFunctions() in order to find a lambdas operator()() but using FindSymbolsMatchingRegExAndType() is cheaper and if we also anchor the regex using ^ this adds some additional performance gains. Differential Revision: https://reviews.llvm.org/D61759 llvm-svn: 360599
* [NativePDB] Fix tests after r360569Aleksandr Urakov2019-05-131-6/+0
| | | | llvm-svn: 360587
* DWARF/DIERef: remove non-const operator<Pavel Labath2019-05-131-2/+0
| | | | | | It serves no purpose as one can always invoke the const version instead. llvm-svn: 360583
* Add REQUIRES: windows to NativePDB/stack_unwinding01.cppPavel Labath2019-05-131-2/+2
| | | | | | | The test runs the compiled executable. As such, it can only work on windows hosts. llvm-svn: 360576
* Breakpad: Generate unwind plans from STACK CFI recordsPavel Labath2019-05-135-2/+298
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the GetUnwindPlan interface (added in the previous patch) for SymbolFileBreakpad, and uses it to generate unwind plans from STACK CFI records in breakpad files. We first perform a light-weight parse of the breakpad in order to build up a map of regions covered by the unwind info so that we can later jump to the right record when we need to unwind a specific function. The actual parsing is relatively straight-forward, as the STACK CFI records are just another (text) form of the eh_frame unwind instructions, and the same goes for lldb's UnwindPlans. The newly-introduced PostfixExpression API is used to convert the breakpad postfix expressions into DWARF. The generated dwarf expressions are stored in a BumpPtrAllocator, as the UnwindPlan does not take ownership of the expression data it references (usually this is static data in an object file, so special ownership is needed). At this moment the generated unwind plans aren't used in the actual unwind machinery (only in the image show-unwind command), but that is coming in a separate patch. Reviewers: amccarth, clayborg, markmentovai Subscribers: aprantl, jasonmolenda, lldb-commits Differential Revision: https://reviews.llvm.org/D61733 llvm-svn: 360574
* Fix flakiness in lldb lit testStefan Granitz2019-05-131-1/+0
| | | | | | | | Messages "breakpoint locations added" and "process stopped" may come out of order. Differential Revision: https://reviews.llvm.org/D61611#anchor-1499662 llvm-svn: 360571
* [NativePDB] Support member function types in PdbAstBuilderAleksandr Urakov2019-05-134-0/+75
| | | | | | | | | | | | | | | | | Summary: This patch implements missing case in PdbAstBuilder::CreateType for LF_MFUNCTION. This is necessary, for example, in stack unwinding of struct methods. Reviewers: amccarth, aleksandr.urakov Reviewed By: amccarth Subscribers: abidh, teemperor, lldb-commits, leonid.mashinskiy Differential Revision: https://reviews.llvm.org/D61128 llvm-svn: 360569
* minidump: Use yaml instead of checked-in binaries for ThreadList testsPavel Labath2019-05-135-30/+41
| | | | | | yaml2obj now supports the ThreadList stream. llvm-svn: 360568
* [DWARF] Use sequential integers for the IDs of the SymbolFileDWOsPavel Labath2019-05-132-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of using the offset of the contained compile unit, we use it's ID. The goal of this change is two-fold: - free up space in the user_id_t representation to enable storing the debug-info-carrying section (debug_types/debug_info) without decreasing the amount of debug info we can address (as would be the case with D61503). - be a step towards supporting DWO files containing more than one unit (important for debug_types+dwo, but can also happen with regular dwo+lto). For this part to fully work we'd still need to add a way to lookup the SymbolFileDWO without going through GetCompileUnitAtIndex, but making sure things don't accidentally work because the SymbolFile ID is the same as compile unit offset is a step towards that. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mehdi_amini, dexonsmith, tberghammer, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61783 llvm-svn: 360565
* @skipIfLinux flaky lldb-mi testsPavel Labath2019-05-134-1/+5
| | | | llvm-svn: 360564
* Remove declaratons of deleted structs/classesFangrui Song2019-05-131-11/+0
| | | | llvm-svn: 360562
* [CMake] Add lli to LLDB_TEST_DEPSFangrui Song2019-05-131-0/+1
| | | | | | | lli is used by lit/Breakpoint/jitbp_elf.test I had a test failure when running check-lldb-lit because my lli was stale. llvm-svn: 360557
* Fix file names in file headers. NFCFangrui Song2019-05-1341-43/+43
| | | | llvm-svn: 360554
* [Breakpoint] Make breakpoint language agnosticAlex Langford2019-05-115-59/+76
| | | | | | | | | | | | | | | | | | | Summary: Breakpoint shouldn't need to depend on any specific details from a programming language. Currently the only language-specific detail it takes advantage of are the different qualified names an objective-c method name might have when adding a name lookup. This is reasonably generalizable. The current method name I introduced is "GetVariantMethodNames", which I'm not particularly tied to. If you have a better suggestion, please do let me know. Reviewers: JDevlieghere, jingham, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D61746 llvm-svn: 360509
* Change the disabling of packet logging to be in TearDownHook lambdas.Jason Molenda2019-05-104-12/+9
| | | | llvm-svn: 360482
* Ted pointed out that some of test tests that are enabling packetJason Molenda2019-05-104-7/+17
| | | | | | | | logging when the testsuite is run with trace mode enabled are leaving the logging enabled after the tests have finished. That state isn't cleared in a --no-multiprocess testsuite run. llvm-svn: 360480
* Finish renaming CompileUnit -> UnitJan Kratochvil2019-05-1012-93/+85
| | | | | | | | | | | | | D42892 changed a lot of code to use superclass DWARFUnit instead of its subclass DWARFCompileUnit. Finish this change more thoroughly for any *CompileUnit* -> *Unit* names. Later patch will introduce DWARFTypeUnit which needs to be sometimes different from DWARFCompileUnit and it would be confusing without this renaming. Differential Revision: https://reviews.llvm.org/D61501 llvm-svn: 360443
* minidump: Don't eagerly resolve module paths read from the minidumpPavel Labath2019-05-103-2/+29
| | | | | | | | This can cause us to return paths to files on the local filesystem even if we don't end up using that file (for instance because the file is not a real module). llvm-svn: 360432
* [lldb] [lit] Fix clobbers in x86_64 register testMichal Gorny2019-05-101-2/+2
| | | | llvm-svn: 360423
* Minidump: use ThreadList parsing code from llvm/ObjectPavel Labath2019-05-109-105/+50
| | | | llvm-svn: 360412
* FuncUnwinders: Add a new "SymbolFile" unwind planPavel Labath2019-05-107-3/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: some unwind formats are specific to a single symbol file and so it does not make sense for their parsing code live in the general Symbol library (as is the case with eh_frame for instance). This is the case for the unwind information in breakpad files, but the same will probably be true for PDB unwind info (once we are able to parse that). This patch adds the ability to fetch an unwind plan provided by a symbol file plugin, as discussed in the RFC at <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. I've kept the set of changes to a minimum, as there is no way to test them until we have a symbol file which implements this API -- that is comming in a follow-up patch, which will also implicitly test this change. The interesting part here is the introduction of the "RegisterInfoResolver" interface. The reason for this is that breakpad needs to be able to resolve register names (which are present as strings in the file) into register enums so that it can construct the unwind plan. This is normally done via the RegisterContext class, handing this over to the SymbolFile plugin would mean that it has full access to the debugged process, which is not something we want it to have. So instead, I create a facade, which only provides the ability to query register names, and hide the RegisterContext behind the facade. Also note that this only adds the ability to dump the unwind plan created by the symbol file plugin -- the plan is not used for unwinding yet -- this will be added in a third patch, which will add additional tests which makes sure the unwinding works as a whole. Reviewers: jasonmolenda, clayborg Subscribers: markmentovai, amccarth, lldb-commits Differential Revision: https://reviews.llvm.org/D61732 llvm-svn: 360409
* Revert "Disable the step over skipping calls feature since buildbots are not ↵Pavel Labath2019-05-103-4/+2
| | | | | | | | | | | | | | | | happy." While this fixed the windows bot failures, it also broke all other bots. Upon closer inspection, it turns out that the windows bots were "broken" because two tests were unexpectedly passing -- i.e., the original patch (r360375) actually improved our stepping support on windows. So instead, I remove the relevant XFAILs. This reverts commit r360397. llvm-svn: 360407
* [Docs] Fix table formatting in Pytho referenceJonas Devlieghere2019-05-101-98/+98
| | | | llvm-svn: 360398
* Disable the step over skipping calls feature since buildbots are not happy.Greg Clayton2019-05-101-2/+2
| | | | llvm-svn: 360397
* [Docs] Port python reference pageJonas Devlieghere2019-05-092-0/+823
| | | | | | | I somehow forgot to port over this page from the old website. Thank you Jim for the heads up! llvm-svn: 360386
* Improve step over performance by not stopping at branches that are function ↵Greg Clayton2019-05-095-10/+38
| | | | | | | | | | calls and stepping into and them out of each one Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue. Differential Revision: https://reviews.llvm.org/D58678 llvm-svn: 360375
* Fix TestVSCode_attach on LinuxStella Stamenova2019-05-091-4/+7
| | | | | | The test is failing sometimes because the debugger is failing to attach for lack of permissions. The fix is to call lldb_enable_attach inside the inferior main function llvm-svn: 360371
* Use UNSUPPORTED: system-windows instead of REQUIRES: nowindows or ↵Stella Stamenova2019-05-091-1/+1
| | | | | | UNSUPPORTED: windows. nowindows is not currently defined and windows does not cover all cases. system-windows is also consistent with how other platforms are used. llvm-svn: 360368
* [lldb] build.py: fix behavior when passing --compiler=/path/to/compilerJorge Gorbe Moya2019-05-092-6/+16
| | | | | | | | | | | | | | | All the other paths in the find_toolchain function return a tuple (detected_toolchain_type, compiler_path), but when the parameter to --compiler is not one of the predefined names it only returns the detected toolchain type, which causes an error when trying to unpack the result. This patch changes it to return also the compiler path passed as a parameter. Differential Revision: https://reviews.llvm.org/D61713 llvm-svn: 360355
* [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptorsStefan Granitz2019-05-095-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First part of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's is still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 The address of the breakpoint site is corrupt: the 0x4 value we end up with, looks like an offset on a zero base address. When we parse the ELF section headers from the JIT descriptor, the load address for the text section we find in `header.sh_addr` is correct. The bug manifests in `VMAddressProvider::GetVMRange(const ELFSectionHeader &)` (follow it from `ObjectFileELF::CreateSections()`). Here we think the object type was `eTypeObjectFile` and unleash some extra logic [1] which essentially overwrites the address with a zero value. The object type is deduced from the ELF header's `e_type` in `ObjectFileELF::CalculateType()`. It never returns `eTypeJIT`, because the ELF header has no representation for it [2]. Instead the in-memory ELF object states `ET_REL`, which leads to `eTypeObjectFile`. This is what we get from `lli` at least since 3.x. (Might it be better to write `ET_EXEC` on the JIT side instead? In fact, relocations were already applied at this point, so "Relocatable" is not quite exact.) So, this patch proposes to set `eTypeJIT` explicitly whenever we read from a JIT descriptor. In `ObjectFileELF::CreateSections()` we can then call `GetType()`, which returns the explicit value or otherwise falls back to `CalculateType()`. LLDB then sets the breakpoint successfully. Next step: debug info. ``` Process 1056 stopped * thread #1, name = 'lli', stop reason = breakpoint 1.2 frame #0: 0x00007ffff7ff7000 JIT(0x3ba2030)`jitbp() JIT(0x3ba2030)`jitbp: -> 0x7ffff7ff7000 <+0>: pushq %rbp 0x7ffff7ff7001 <+1>: movq %rsp, %rbp 0x7ffff7ff7004 <+4>: movabsq $0x7ffff7ff6000, %rdi ; imm = 0x7FFFF7FF6000 0x7ffff7ff700e <+14>: movabsq $0x7ffff6697e80, %rcx ; imm = 0x7FFFF6697E80 ``` [1] It was first introduced with https://reviews.llvm.org/D38142#change-lF6csxV8HdlL, which has also been the original breaking change. The code has changed a lot since then. [2] ELF object types: https://github.com/llvm/llvm-project/blob/2d2277f5/llvm/include/llvm/BinaryFormat/ELF.h#L110 Reviewers: labath, JDevlieghere, bkoropoff, clayborg, espindola, alexshap, stella.stamenova Reviewed By: labath, clayborg Subscribers: probinson, emaste, aprantl, arichardson, MaskRay, AlexDenisov, yurydelendik, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61611 llvm-svn: 360354
* Fix up lldb after clang r360311.Richard Smith2019-05-091-2/+6
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360312
* Fix the output file dependency for Options.inc.Jim Ingham2019-05-091-1/+1
| | | | | | | | The script phase to do Options.td -> Options.inc was wrong (missing the "include" directory) so the rule didn't get run when Options.td changed. llvm-svn: 360304
* [Reproducers] Fix reproducer unittestJonas Devlieghere2019-05-081-1/+3
| | | | | | | | | | | | | | | I think the recent change to flush the SB API recording uncovered a real issue on the Windows bot. Although I couldn't make much sense of the error message "unknown file: error: SEH exception with code 0x3221225477 thrown in the test body.", it prompted me to look at the test. In the unit test we were recording during replay, which is obviously not correct. I think we didn't see this issue before because we flushed once after the recording was done. This patch unsets the recording logic during the replay part of the test. Hopefully this fixed the Windows bot. llvm-svn: 360298
* Fix bug in ArchSpec::MergeFromGreg Clayton2019-05-082-1/+27
| | | | | | | | | | Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this. This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly. Differential Revision: https://reviews.llvm.org/D61659 llvm-svn: 360292
* [Reproducers] Flush files to disk periodicallyJonas Devlieghere2019-05-082-1/+4
| | | | | | | Periodically flush some of the data to disk. Although not perfect, this helps when the debugger crashes. llvm-svn: 360286
* [Reproducers] Fix unitialized pointerJonas Devlieghere2019-05-081-1/+1
| | | | | | | The FileCollector pointer in the FileSystem class wasn't initialized to nullptr during replay. llvm-svn: 360285
* [Docs] list command: lldb run <args>Jonas Devlieghere2019-05-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The run command is only an abbreviation for the more verbose process launch -- <args> but it works just as with GDB and therefore should be mentioned in the GDB to LLDB command map. For educational purposes I've not listed it as the first option on the LLDB side so that new LLDB user can, if they want, also know what the "native" way is for LLDB. Here's the help documentation for the run command in lldb which gives proof: > (lldb) help run > Launch the executable in the debugger. > > Syntax: run [<run-args>] > > Command Options Usage: > run [<run-args>] > > 'run' is an abbreviation for 'process launch -c /bin/sh --' Patch by: Konrad Kleine Differential revision: https://reviews.llvm.org/D61483 llvm-svn: 360269
* [DWARF] Centralize user_id <-> DWARFDIE conversionsPavel Labath2019-05-086-114/+55
| | | | | | | | | | | | | | | | | | | | | | | Summary: The logic for translating a user_id into a DWARFDIE was replicated in several places. This removes that redundancy and settles on a single implementation in SymbolFileDWARF. The reason for choosing that instead of DIERef was that we were always immediately converting the returned DIERef into a DWARFDIE anyway, which meant that one had to specify the SymbolFileDWARF argument twice (once to get the DIERef, and once to get the actual DIE). Also, passing a higher-level object (SymbolFileDWARF) into a lower-level one (DIERef) seemed like a less intuitive arrangement than doing things the other way around. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: tberghammer, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61648 llvm-svn: 360246
* [Docs] Fix incorrect heading and update titles.Jonas Devlieghere2019-05-083-9/+9
| | | | | | | | This patch fixes two incorrect headings in source.rst which caused it to show up on the homepage. I also updated the titles to have more sensible links there. llvm-svn: 360219
* [Docs] Re-order homepage: Download -> Build -> TestJonas Devlieghere2019-05-082-14/+17
| | | | | | I also reformatted some paragraphs to 80 cols. llvm-svn: 360218
* Propagate command interpreter errors from lldlbinitJonas Devlieghere2019-05-0811-8/+48
| | | | | | | | | | | | | | This patch ensures that we propagate errors coming from the lldbinit file trough the command/script interpreter. Before, if you did something like command script import syntax_error.py, and the python file contained a syntax error, lldb wouldn't tell you about it. This changes with the current patch: errors are now propagated by default. PS: Jim authored this change and I added testing. Differential revision: https://reviews.llvm.org/D61579 llvm-svn: 360216
* [Docs] Add timestampJonas Devlieghere2019-05-071-1/+1
| | | | llvm-svn: 360209
* [Expression] Remove unused dependencyAlex Langford2019-05-073-4/+1
| | | | | | | | | lldbExpression was linking against lldbPluginExpressionParserClang, and lldbPluginExpressionParserClang was linking against lldbExpression. There's no reason lldbExpression should need anything from lldbPluginExpressionParserClang, so let's remove that dependency. llvm-svn: 360208
* [Core] Remove unused dependenciesAlex Langford2019-05-071-2/+0
| | | | llvm-svn: 360193
OpenPOWER on IntegriCloud