summaryrefslogtreecommitdiffstats
path: root/lldb/lit/SymbolFile
Commit message (Collapse)AuthorAgeFilesLines
* Re-land "[test] Split LLDB tests into API, Shell & Unit"Jonas Devlieghere2019-10-09166-9456/+0
| | | | | | | The original patch got reverted because it broke `check-lldb` on a clean build. This fixes that. llvm-svn: 374201
* Update breakpad lit test to be independent of the unnamed symbol numberAntonio Afonso2019-10-091-1/+1
| | | | llvm-svn: 374192
* Revert [test] Split LLDB tests into API, Shell & UnitAdrian Prantl2019-10-09166-0/+9456
| | | | | | | | as it appears to have broken check-lldb. This reverts r374184 (git commit 22314179f0660c172514b397060fd8f34b586e82) llvm-svn: 374187
* [test] Split LLDB tests into API, Shell & UnitJonas Devlieghere2019-10-09166-9456/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLDB has three major testing strategies: unit tests, tests that exercise the SB API though dotest.py and what we currently call lit tests. The later is rather confusing as we're now using lit as the driver for all three types of tests. As most of this grew organically, the directory structure in the LLDB repository doesn't really make this clear. The 'lit' tests are part of the root and among these tests there's a Unit and Suite folder for the unit and dotest-tests. This layout makes it impossible to run just the lit tests. This patch changes the directory layout to match the 3 testing strategies, each with their own directory and their own configuration file. This means there are now 3 directories under lit with 3 corresponding targets: - API (check-lldb-api): Test exercising the SB API. - Shell (check-lldb-shell): Test exercising command line utilities. - Unit (check-lldb-unit): Unit tests. Finally, there's still the `check-lldb` target that runs all three test suites. Finally, this also renames the lit folder to `test` to match the LLVM repository layout. Differential revision: https://reviews.llvm.org/D68606 llvm-svn: 374184
* Explicitly set entry point arch when it's thumb [Second Try]Antonio Afonso2019-10-083-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
* Add pretty printing of Clang "bitfield" enumsFrederic Riss2019-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Using enumerators as flags is standard practice. This patch adds support to LLDB to display such enum values symbolically, eg: (E) e1 = A | B If enumerators don't cover the whole value, the remaining bits are displayed as hexadecimal: (E) e4 = A | 0x10 Detecting whether an enum is used as a bitfield or not is complicated. This patch implements a heuristic that assumes that such enumerators will either have only 1 bit set or will be a combination of previous values. This patch doesn't change the way we currently display enums which the above heuristic would not consider as bitfields. Reviewers: jingham, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67520 llvm-svn: 374067
* Revert "Explicitly set entry point arch when it's thumb"Antonio Afonso2019-10-041-13/+0
| | | | | | | | Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate. This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be. llvm-svn: 373687
* Explicitly set entry point arch when it's thumbAntonio Afonso2019-10-041-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Subscribers: srhines, emaste, arichardson, kristof.beyls, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68069 llvm-svn: 373680
* Use llvm for dumping DWARF expressionsPavel Labath2019-09-302-3/+3
| | | | | | | | | | | | | | | Summary: It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo structs (which is what is needed to turn dwarf register numbers into strings). Reviewers: JDevlieghere, aprantl, jasonmolenda Subscribers: tatyana-krasnukha, lldb-commits Differential Revision: https://reviews.llvm.org/D67966 llvm-svn: 373208
* Unwind: Add a stack scanning mechanism to support win32 unwindingPavel Labath2019-09-273-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Windows unwinding is weird. The unwind rules do not (always) describe the precise layout of the stack, but rather expect the debugger to scan the stack for something which looks like a plausible return address, and the unwind based on that. The reason this works somewhat reliably is because the the unwinder also has access to the frame sizes of the functions on the stack. This allows it (in most cases) to skip function pointers in local variables or function arguments, which could otherwise be mistaken for return addresses. Implementing this kind of unwind mechanism in lldb was a bit challenging because we expect to be able to statically describe (in the UnwindPlan) structure, the layout of the stack for any given instruction. Giving a precise desription of this is not possible, because it requires correlating information from two functions -- the pushed arguments to a function are considered a part of the callers stack frame, and their size needs to be considered when unwinding the caller, but they are only present in the unwind entry of the callee. The callee may end up being in a completely different module, or it may not even be possible to determine it statically (indirect calls). This patch implements this functionality by introducing a couple of new APIs: SymbolFile::GetParameterStackSize - return the amount of stack space taken up by parameters of this function. SymbolFile::GetOwnFrameSize - the size of this function's frame. This excludes the parameters, but includes stuff like local variables and spilled registers. These functions are then used by the unwinder to compute the estimated location of the return address. This address is not always exact, because the stack may contain some additional values -- for instance, if we're getting ready to call a function then the stack will also contain partially set up arguments, but we will not know their size because we haven't called the function yet. For this reason the unwinder will crawl up the stack from the return address position, and look for something that looks like a possible return address. Currently, we assume that something is a valid return address if it ends up pointing to an executable section. All of this logic kicks in when the UnwindPlan sets the value of CFA as "isHeuristicallyDetected", which is also the final new API here. Right now, only SymbolFileBreakpad implements these APIs, but in the future SymbolFilePDB will use them too. Differential Revision: https://reviews.llvm.org/D66638 llvm-svn: 373072
* [test] Add -z separate-code to fix tests that ae sensitive to exact ↵Fangrui Song2019-09-166-6/+6
| | | | | | addresses after r371958 llvm-svn: 371962
* Breakpad: Basic support for STACK WIN unwindingPavel Labath2019-09-053-0/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes it possible to unwind via breakpad STACK WIN records. It is "basic" because two important features are missing: - support for the .raSearch keyword - support for multiple STACK WIN records within a single function Right now, we just reject the .raSearch records, and always pick the first record for the whole function SymbolFileBreakpad, and so I think it can serve as a good example of what is needed of the symbol file and unwinding machinery to make this work. However, it is already useful for unwinding in some situations, and it sets up the general framework for the parsing of these kinds of records, which reduces the size of the followup patches implementing the two other components. Reviewers: amccarth, rnk, markmentovai Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67067 llvm-svn: 371017
* Remove DWARFExpression::LocationListSizePavel Labath2019-08-291-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The only reason for this function's existance is so that we could pass the correct size into the DWARFExpression constructor. However, there is no harm in passing the entire data extractor into the DWARFExpression, since the same code is performing the size determination as well as the subsequent parse. So, if we get malformed input or there's a bug in the parser, we'd compute the wrong size anyway. Additionally, reducing the number of entry points into the location list parsing machinery makes it easier to switch the llvm debug_loc(lists) parsers. While inside, I added a couple of tests for invalid location list handling. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D66789 llvm-svn: 370373
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-5/+8
| | | | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
* Revert Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-8/+5
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-5/+8
| | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
* Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl2019-08-211-2/+16
| | | | | | | | | | | | | | | This patch generalizes the FindTypes with CompilerContext interface to support looking up a type of unknown kind by name, as well as looking up a type inside an unspecified submodule. These features are motivated by the Swift branch, but are fully tested via unit tests and lldb-test on llvm.org. Specifically, this patch adds an AnyModule and an AnyType CompilerContext kind. Differential Revision: https://reviews.llvm.org/D66507 rdar://problem/54471165 llvm-svn: 369555
* Make the FindTypes(std::vector<CompilerContext>, ...) API testable in lldb-testAdrian Prantl2019-08-202-1/+36
| | | | | | | | | | | | | This adds a -compiler-context=<...> option to lldb-test that trakes a comma-separated string that is a list of kind/name pairs and translates it into a std::vector<CompilerContext>, a CompilerContext being a pair of context-kind and name. Differential Revision: https://reviews.llvm.org/D66453 <rdar://problem/54471165> llvm-svn: 369407
* Add support for deterministically linked binaries on macOS to lldb.Nico Weber2019-08-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When ld64 links a binary deterministically using the flag ZERO_AR_DATE, it sets a timestamp of 0 for N_OSO members in the symtab section, rather than the usual last modified date of the object file. Prior to this patch, lldb would compare the timestamp from the N_OSO member against the last modified date of the object file, and skip loading the object file if there was a mismatch. This patch updates the logic to ignore the timestamp check if the N_OSO member has timestamp 0. The original logic was added in https://reviews.llvm.org/rL181631 as a safety check to avoid problems when debugging if the object file was out of date. This was prior to the introduction of deterministic build in ld64. lld still doesn't support deterministic build. Other code in llvm already relies on and uses the assumption that a timestamp of 0 means deterministic build. For example, commit 9ccfddc39d4d27f9b16fcc72ab30d483151d6d08 adds similar timestamp checking logic to dsymutil, but special cases timestamp 0. Likewise, commit 0d1bb79a0413f221432a7b1d0d2d10c84c4bbb99 adds a long comment describing deterministic archive, which mostly uses timestamp 0 for determinism. Patch from Erik Chen <erikchen@chromium.org>! Differential Revision: https://reviews.llvm.org/D65826 llvm-svn: 368199
* A more robust way of testing debug_line parser near the end of modulePavel Labath2019-08-072-3/+28
| | | | | | | | | | | | | | | | | | Summary: While removing -z separate-code makes lld produce place the code at the end of a segment right now, it's possible that future changes to the linker will change that, thereby removing the coverage for the changes in r367983. This patch adds a linker script to one of the line table tests, which ensures that the code (and its line table) will be placed at the very end of a module. Reviewers: MaskRay Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65789 llvm-svn: 368154
* Fix line table resolution near the end of a sectionPavel Labath2019-08-065-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lld r367537 changed the way the linker organizes sections and segments. This exposed an lldb bug and caused some tests to fail. In all of the failing tests the root cause was the same -- when we were trying to resolve the last address in the line_table section, we failed because it pointed past the end of the section. This patch changes the line table address resolution code to back up the address by one for end-of-sequence entries. This ensures the address still points inside a section/module even if the line table sequence ends at the very end of a section. It also reverts the linker flags which were added to the failing tests to restore previous behavior. Reviewers: clayborg, jingham Subscribers: mgorny, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65647 llvm-svn: 367983
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367867
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | | | debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. llvm-svn: 367861
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367850
* Fix PDB tests after r367820Pavel Labath2019-08-056-6/+6
| | | | | | | | | | | The commit changed Module dumping code to call SymbolFile::Dump directly, which meant that we were no longer showing the plugin name in the output (as that was done in the SymbolVendor). This adds the plugin name printing code to the SymbolFile dump method, and tweak the assertions in the PDB tests to match it correctly. llvm-svn: 367835
* [lit] Use ld.lld -z separate-code to work around a debug_line parsing bugFangrui Song2019-08-015-5/+5
| | | | | | | | | | | | | The issue was exposed by D64903/r367537. http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7321/ In these tests, .debug_str immediately follows .text. The last section of last RX PT_LOAD was originally padded with trap instructions and .debug_str started at a new page (actually common-page-size). Now, .debug_str immediately follows .test. Add -z separate-code to use the old layout. llvm-svn: 367549
* ObjectFileELF: Add support for gnu-style compressed sectionsPavel Labath2019-07-101-0/+14
| | | | | | | | | With this style, a compressed section is indicated by a "z" in the section name, instead of a section header flag. This patch consists of two small tweaks: - use an llvm Decompressor method in order to properly detect compressed sections - make sure we recognise .zdebug_info (and friends) when classifying section types. llvm-svn: 365654
* [DWARF] Add one more type unit testPavel Labath2019-07-021-0/+37
| | | | | | | This test passes already, but it seems interesting to test that we can jump between type units in different dwo files nonetheless. llvm-svn: 364890
* Fix lookup of symbols at the same address with no size vs. sizeJan Kratochvil2019-07-012-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30): PASS: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325 frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243 frame #7: 0x000000000040106e a.out`_start + 46 vs. FAIL - unrecognized abort() function: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325 frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243 frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46 The extra ELF symbols are there due to Annobin (I did not investigate why this problem happened specifically since F-30 and not since F-28). It is due to: Symbol table '.dynsym' contains 2361 entries: Valu e Size Type Bind Vis Name 0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely 000000000002276e 548 FUNC GLOBAL DEFAULT abort 000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5 000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort 0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely Differential Revision: https://reviews.llvm.org/D63540 llvm-svn: 364773
* DWARF: Add support for type units+split dwarf comboPavel Labath2019-06-253-10/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With the last round of refactors, supporting type units in dwo files becomes almost trivial. This patch contains a couple of small fixes, which taken as a whole make type units work in the split dwarf scenario (both DWARF4 and DWARF5): - DWARFContext: make sure we actually read the debug_types.dwo section - DWARFUnit: set string offsets base on all units in the dwo file, not just the main CU - ManualDWARFIndex: index all units in the file - SymbolFileDWARFDwo: Search for the single compile unit in the file, as we can no longer assume it will be the first one The last part makes it obvious that there is still some work to be done here, namely that we do not support dwo files with multiple compile units. That is something that should be easier after the DIERef refactors, but it still requires more work. Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as well as a test that checks we behave reasonably in the presence of dwo files with multiple CUs. Reviewers: clayborg, JDevlieghere, aprantl Subscribers: arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D63643 llvm-svn: 364274
* DWARF: Add "dwo_num" field to the DIERef classPavel Labath2019-06-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When dwo support was introduced, it used a trick where debug info entries were referenced by the offset of the compile unit in the main file, but the die offset was relative to the dwo file. Although there was some elegance to it, this representation was starting to reach its breaking point: - the fact that the skeleton compile unit owned the DWO file meant that it was impossible (or at least hard and unintuitive) to support DWO files containing more than one compile unit. These kinds of files are produced by LTO for example. - it made it impossible to reference any DIEs in the skeleton compile unit (although the skeleton units are generally empty, clang still puts some info into them with -fsplit-dwarf-inlining). - (current motivation) it made it very hard to support type units placed in DWO files, as type units don't have any skeleton units which could be referenced in the main file This patch addresses this problem by introducing an new "dwo_num" field to the DIERef class, whose purpose is to identify the dwo file. It's kind of similar to the dwo_id field in DWARF5 unit headers, but while this is a 64bit hash whose main purpose is to catch file mismatches, this is just a smaller integer used to indentify a loaded dwo file. Currently, this is based on the index of the skeleton compile unit which owns the dwo file, but it is intended to be eventually independent of that (to support the LTO use case). Simultaneously the cu_offset is dropped to conserve space, as it is no longer necessary. This means we can remove the "BaseObjectOffset" field from the DWARFUnit class. It also means we can remove some of the workarounds put in place to support the skeleton-unit+dwo-die combo. More work is needed to remove all of them, which is out of scope of this patch. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D63428 llvm-svn: 364009
* DWARF: Don't create lldb CompileUnits for DWARF type unitsPavel Labath2019-06-132-0/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Type units don't represent actual compilations and a lot of the operations that we do with lldb compile units (getting their line tables, variables, etc.) don't make sense for them. There is also a lot more of them (sometimes over 100x), so making them more lightweight pays off. The main change in this patch is that we stop creating lldb CompileUnits for DWARF type units. The trickiest part here is that the SymbolFile interface requires that we assign consecutive sequence IDs to the compile units we create. As DWARF type and compile units can come in any order (in v5), this means we can no longer use 1-1 mapping between DWARF and lldb compile units. Instead I build a translation table between the two indices. To avoid pessimizing the case where there are no type units, I build the translation table only in case we have at least one type unit. Additionaly, I also tried to strenghted type safete by replacing DWARFUnit with DWARFCompileUnit where applicable. Though that was not stricly necessary, I found it a good way to ensure that the transformations I am doing here make sense. In the places where I was changing the function signatures, and where it was obvious that the objects being handled were not null, I also replaced pointers with references. There shouldn't be any major functional change with this patch. The only change I observed is that now the types in the type units will not be parsed when one calls Module::ParseAllDebugSymbols, unless they are referenced from other compile units. This makes sense, given how ParseAllDebugSymbols is implemented (it iterates over all compile units), and it only matters for one hand-writted test where I did not bother to reference the types from the compile units (which I now do). Reviewers: clayborg, JDevlieghere, aprantl Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D63005 llvm-svn: 363250
* DWARF: Share line tables of type unitsPavel Labath2019-06-122-0/+296
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch creates a cache of file lists in line tables referenced by type units. This cache is used to avoid parsing a line table twice (since a file list will generally be shared by many type units). It also sets things up in a way that parsing of DW_AT_decl_file attributes will keep working even when we stop creating lldb compile units for dwarf type units, but it stops short of actually doing that. This means that the request for files now go directly to SymbolFileDWARF instead of being routed there indirectly via the lldb_private::CompileUnit class. As a result of this, a number of occurences of SymbolContext variables in DWARFASTParserClang have become unused, so I remove them. This patch reduces the number of times a file list is being parsed, but the situation is still suboptimal, as the parsed list is being copied multiple times. This will be fixed when we stop creating CompileUnits for DWARF type units. Reviewers: clayborg, aprantl, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D62894 llvm-svn: 363143
* Add "REQUIRES: x86" to DWARF assembly testsPavel Labath2019-06-1017-10/+26
| | | | | | | These tests don't require an x86 host, but they do require that we build the x86 llvm target. llvm-svn: 362948
* Ignore DIEs in the skeleton unit in a DWO scenarioPavel Labath2019-06-051-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r362103 exposed a bug, where we could read incorrect data if a skeleton unit contained more than the single unit DIE. Clang emits these kinds of units with -fsplit-dwarf-inlining (which is also the default). Changing lldb to handle these DIEs is nontrivial, as we'd have to change the UID encoding logic to be able to reference these DIEs, and fix up various places which are assuming that all DIEs come from the separate compile unit. However, it turns out this is not necessary, as the DWO unit contains all the information that the skeleton unit does. So, this patch just skips parsing the extra DIEs if we have successfully found the DWO file. This enforces the invariant that the rest of the code is already operating under. This patch fixes a couple of existing tests, but I've also included a simpler test which does not depend on execution of binaries, and would have helped us in catching this sooner. Reviewers: clayborg, JDevlieghere, aprantl Subscribers: probinson, dblaikie, lldb-commits Differential Revision: https://reviews.llvm.org/D62852 llvm-svn: 362586
* DWARF: Fix address range support in mixed 4+5 scenarioPavel Labath2019-05-292-1/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: debug_ranges got renamed to debug_rnglists in DWARF 5. Prior to this patch lldb was just picking the first section it could find in the file, and using that for all address ranges lookups. This is not correct in case the file contains a mixture of compile units with various standard versions (not a completely unlikely scenario). In this patch I make lldb support reading from both sections simulaneously, and decide the correct section to use based on the version number of the compile unit. SymbolFileDWARF::DebugRanges is split into GetDebugRanges and GetDebugRngLists (the first one is renamed mainly so we can catch all incorrect usages). I tried to structure the code similarly to how llvm handles this logic (hence DWARFUnit::FindRnglistFromOffset/Index), but the implementations are still relatively far from each other. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62302 llvm-svn: 361938
* DWARF: Add a simple test exercising debug_loc parsingPavel Labath2019-05-271-0/+117
| | | | llvm-svn: 361759
* [FuncUnwinders] Use "symbol file" unwind plans for unwindingPavel Labath2019-05-244-0/+73
| | | | | | | | | | | | | | | | | Summary: Previous patch (r360409) introduced the "symbol file unwind plan" concept, but that plan wasn't used for unwinding yet. With this patch, we start to consider the new plan as a possible strategy for both synchronous and asynchronous unwinding. I also add a test that asserts that unwinding via breakpad STACK CFI info works end-to-end. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, amccarth, markmentovai Differential Revision: https://reviews.llvm.org/D61853 llvm-svn: 361618
* DWARF: Implement DW_AT_signature lookup for type unit supportPavel Labath2019-05-246-4/+178
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the main feature of type units. When completing a type, if we encounter a DW_AT_signature attribute, we use it's value to lookup the complete definition of the type in the relevant type unit. To enable this lookup, we build up a map of all type units in a symbol file when parsing the units. Then we consult this map when resolving the DW_AT_signature attribute. I include add a couple of tests which exercise the type lookup feature, including one that ensure we do something reasonable in case we fail to lookup the type. A lot of the ideas in this patch have been taken from D32167 and D61505. Reviewers: clayborg, JDevlieghere, aprantl, alexshap Subscribers: mgrang, lldb-commits Differential Revision: https://reviews.llvm.org/D62246 llvm-svn: 361603
* DWARFContext: Make loading of sections thread-safePavel Labath2019-05-241-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SymbolFileDWARF used to load debug sections in a thread-safe manner. When we moved to DWARFContext, we dropped the thread-safe part, because we thought it was not necessary. It turns out this was only mostly correct. The "mostly" part is there because this is a problem only if we use the manual index, as that is the only source of intra-module paralelism. Also, this only seems to occur for extremely simple files (like the ones I've been creating for tests lately), where we've managed to start indexing before loading the debug_str section. Then, two threads start to load the section simultaneously and produce wrong results. On more complex files, something seems to be loading the debug_str section before we start indexing, as I haven't been able to reproduce this there, but I have not investigated what it is. I've tried to come up with a test for this, but I haven't been able to reproduce the problem reliably. Still, while doing so, I created a way to generate many compile units on demand. Given that most of our tests work with only one or two compile units, it seems like this could be useful anyway. Reviewers: aprantl, JDevlieghere, clayborg Subscribers: arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D62316 llvm-svn: 361602
* Add REQUIRES: lld to debug-types-address-ranges.sPavel Labath2019-05-231-0/+2
| | | | | | This should fix the green dragon bots. llvm-svn: 361481
* DWARF: Don't compute address ranges for type unitsPavel Labath2019-05-231-0/+338
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Type units don't describe any code, so they should never be the result of any address lookup queries. Previously, we would compute the address ranges for the type units for via the line tables they reference because the type units looked a lot like line-tables-only compile units. However, this is not correct, as the line tables are only referenced from type units so that other declarations can use the file names contained in them. In this patch I make the BuildAddressRangeTable function virtual, and implement it only for compile units. Testing this was a bit tricky, because the behavior depends on the order in which we add things to the address range map. This rarely caused a problem with DWARF v4 type units, as they are always added after all CUs. It happened more frequently with DWARF v5, as there clang emits the type units first. However, this is still not something that it is required to do, so for testing I've created an assembly file where I've deliberately sandwiched a compile unit between two type units, which should isolate us from both changes in how the compiler emits the units and changes in the order we process them. Reviewers: clayborg, aprantl, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D62178 llvm-svn: 361465
* DWARF: Add debug_ranges/rnglists testsPavel Labath2019-05-223-0/+219
| | | | | | | | | | | | | | | .debug_ranges parsing is not well tested [citation needed] because this section tends to be only used in optimized code, and we don't build optimized executables in our tests, as they produce unpredictable results. This patch aims to add some very simple tests for parsing static range data, which can serve as a first line of defense in case things break. I also include one XFAILed test, which demonstrates that we don't correctly handle mixed DWARF v5 and v4 ranges in a single file. llvm-svn: 361373
* DWARF: Introduce DWARFTypeUnit classPavel Labath2019-05-225-1/+113
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces the DWARFTypeUnit class, and teaches lldb to parse type units out of both the debug_types section (DWARF v4), and from the regular debug_info section (DWARF v5). The most important piece of functionality - resolving DW_AT_signatures to connect type forward declarations to their definitions - is not implemented here, but even without that, a lot of functionality becomes available. I've added tests for the commands that start to work after this patch. The changes in this patch were greatly inspired by D61505, which in turn took over changes from D32167. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mgorny, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D62008 llvm-svn: 361360
* DWARFContext: Return empty data extractors instead of null pointersPavel Labath2019-05-161-0/+63
| | | | | | | | | | | | | | | | | | | | | | | Summary: There are several reasons for doing this: - generally, there's no reason to differentiate between a section being absent and it being present, but empty - it matches more closely what llvm DWARF parser is doing (which also doesn't differentiate the two cases) - SymbolFileDWARF also doesn't differentiate the two cases, which makes porting the rest of sections easier - it fixes a bug in how the return-null-if-empty logic was implemented (it returned nullptr only the second time we tried to get the debug_aranges section), which meant that we hit an assert when trying to parse an empty-but-present section Reviewers: JDevlieghere, clayborg, aprantl Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D61942 llvm-svn: 360874
* DWARF: Add ability to reference debug info coming from multiple sectionsPavel Labath2019-05-162-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to precisely address debug info in situations when a single file can have more than one debug-info-bearing sections (as is the case with type units in DWARF v4). The changes here can be classified into roughly three categories: - the code which addresses a debug info by offset gets an additional argument, which specifies the section one should look into. - the DIERef class also gets an additional member variable specifying the section. This way, code dealing with DIERefs can know which section is the object referring to. - the user_id_t encoding steals one bit from the dwarf_id field to store the section. This means the total number of separate object files (apple .o, or normal .dwo) is limited to 2 billion, but that is fine as it's not possible to hit that number without switching to DWARF64 anyway. This patch is functionally equivalent to (and inspired by) the two patches (D61503 and D61504) by Jan Kratochvil, but there are differences in the implementation: - it uses an enum instead of a bool flag to differentiate the sections - it increases the size of DIERef struct instead of reducing the amount of addressable debug info - it sets up DWARFDebugInfo to store the units in a single vector instead of two. This sets us up for the future in which type units can also live in the debug_info section, and I believe it's cleaner because there's no need for unit index remapping There are no tests with this patch as this is essentially NFC until we start parsing type units from the debug_types section. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: arphaman, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61908 llvm-svn: 360872
* [NativePDB] Fix tests after r360569Aleksandr Urakov2019-05-131-6/+0
| | | | llvm-svn: 360587
* 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-133-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NativePDB] Support member function types in PdbAstBuilderAleksandr Urakov2019-05-132-0/+56
| | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud