summaryrefslogtreecommitdiffstats
path: root/lldb/test
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/DWARF] Move location list sections into DWARFContextPavel Labath2020-01-142-0/+33
| | | | | | These are the last sections not managed by the DWARFContext object. I also introduce separate SectionType enums for dwo section variants, as this is necessary for proper handling of single-file split dwarf.
* Expression eval lookup speedup by not returning methods in ↵Levon Ter-Grigoryan2020-01-141-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | ManualDWARFIndex::GetFunctions Summary: This change is connected with https://reviews.llvm.org/D69843 In large codebases, we sometimes see Module::FindFunctions (when called from ClangExpressionDeclMap::FindExternalVisibleDecls) returning huge amounts of functions. In current fix I trying to return only function_fullnames from ManualDWARFIndex::GetFunctions when eFunctionNameTypeFull is passed as argument. Reviewers: labath, jarin, aprantl Reviewed By: labath Subscribers: shafik, clayborg, teemperor, arphaman, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70846
* [lldb] Fix lookup of symbols with the same address range but different bindingJan Kratochvil2020-01-132-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 GDB has some more complicated preferences between overlapping and/or sharing address symbols, I have made here so far the most simple fix for this case. Differential revision: https://reviews.llvm.org/D63540
* [lldb] Fix eh-frame-small-fde test for changes in lldPavel Labath2020-01-131-8/+3
| | | | | | | | lld in 2bfee35 started emitting relocations for some intra-section jumps between global symbols. This shifted the code around a bit, invalidating text expectations. Change the symbols to local to keep the previous behavior.
* lldbutil: Forward ASan launch info to test inferiorsVedant Kumar2020-01-101-0/+6
| | | | | | | | | This allows an unsanitized test process which loads a sanitized DSO (the motivating example is a Swift runtime dylib) to launch on Darwin. rdar://57290132 Differential Revision: https://reviews.llvm.org/D71379
* [lldb/Test] Bypass LLDB_TEST_COMMON_ARGS for certain dotest args (NFC)Jonas Devlieghere2020-01-103-15/+29
| | | | | | | | Rather than serializing every argument through LLDB_TEST_COMMON_ARGS, we can pass some of them directly using their CMake variable. Although this does introduce some code duplication between lit's site config and the lldb-dotest utility, it also means that it becomes easier to override these values (WIP).
* [lldb/Lua] Support loading Lua modulesJonas Devlieghere2020-01-102-0/+20
| | | | | | Implements the command script import command for Lua. Differential revision: https://reviews.llvm.org/D71825
* [lldb/lua] Make convenience_variables.test compatible with lua-5.1Pavel Labath2020-01-101-5/+5
|
* [lldb/Lua] Make lldb.debugger et al available to LuaJonas Devlieghere2020-01-096-0/+49
| | | | | | | | The Python script interpreter makes the current debugger, target, process, thread and frame available to interactive scripting sessions through convenience variables. This patch does the same for Lua. Differential revision: https://reviews.llvm.org/D71801
* [lldb/DWARF] Fix mixed v4+v5 location listsPavel Labath2020-01-091-0/+154
| | | | | | | | | | | | | | | | | | | | | | Summary: Our code was expecting that a single (symbol) file contains only one kind of location lists. This is not correct (on non-apple platforms, at least) as a file can compile units with different dwarf versions. This patch moves the deteremination of location list flavour down to the compile unit level, fixing this problem. I have also tried to rougly align the code with the llvm DWARFUnit. Fully matching the API is not possible because of how lldb's DWARFExpression lives separately from the rest of the DWARF code, but this is at least a step in the right direction. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71751
* [lldb/Test] Try to appease the Windows botJonas Devlieghere2020-01-071-1/+0
| | | | | | | | | | | | In TestConvenienceVariables I changed %t from a file to a directory. This tripped up mkdir which can't deal with an existing file at the given location. In order to solve this issue on the bots I added an `rm -rf %t` statement, but now the Windows bot complains that "This function is not supported on this system". If you never ran the test suite wit this temporary workaround, the test might fail. If this happens please remove what %t expands to in the lit output and rerun the test.
* [lldb/Test] Remove old binary created by TestConvenienceVariablesJonas Devlieghere2020-01-071-0/+1
| | | | | On a dirty build directory the new mkdir fails because the file already exists and is not a directory.
* [lldb/Test] Make TestConvenienceVariables more strictJonas Devlieghere2020-01-071-14/+11
| | | | | | This test was passing even when the output of lldb.target was empty. I've made the test more strict by checking explicitly for the target name and by using CHECK-NEXT lines.
* [lldb/Test] Disable TestSynchronous.test on Windows.Jonas Devlieghere2019-12-231-0/+1
| | | | | | The test was being skipped on the Windwos bot because it requires Python which was silently disabled because of a configuration issue. Now that the test runs, this fails as expected.
* [lldb/DWARF] Fix hostname-stripping logicPavel Labath2019-12-231-0/+49
| | | | | | | | | | | | | | This bit of code is trying to strip everything up to the first colon from all debug info paths, as dwarf2 recommends this syntax for storing the compilation host name. However, this code was too eager, and it ended up stripping the entire compilation directory, if it did not contain a forward slash (or a "x:\"). Normally this does not matter, as all absolute paths will contain one of these patterns, but this does not have to be the case in case the debug info is produced by "clang -fdebug-compilation-dir", which can end up producing a relative compilation directory with no slashes (this is one of the techniques for producing "relocatable" debug info).
* [lldb/lua] Fix bindings.test for lua-5.1Pavel Labath2019-12-231-1/+1
| | | | | string.format("%s", true) only works since lua-5.2. Make the print statement more portable.
* [lldb/ScriptInterpreter] Unify error message for command script importJonas Devlieghere2019-12-221-0/+2
| | | | | Rather than checking for Python explicitly, let the script interpreter handle things and print an error if the functionality is not supported.
* [lldb/ScriptInterpreter] Fix stale/bogus error messagesJonas Devlieghere2019-12-212-0/+13
| | | | | Fix the nonsensical error messages for when breakpoint and watchpoint callbacks are not supported.
* [lldb/Commands] Honor the scripting language passedJonas Devlieghere2019-12-211-0/+11
| | | | | | This ensures that breakpoint command honors the scripting language passed with `-s`. Currently the argument ignores the actual language and only uses it to differentiate between lldb and script commands.
* [Lldb/Lua] Persist Lua state across script interpreter calls.Jonas Devlieghere2019-12-211-0/+3
| | | | | | Don't create a new lua state on every operation. Share a single state across the lifetime of the script interpreter. Add simple locking to prevent two threads from modifying the state concurrently.
* [Lldb/Lua] Generate Lua BindingsJonas Devlieghere2019-12-211-0/+6
| | | | | | | | | | | This patch uses SWIG to generate the Lua bindings for the SB API. It covers most of the API, but some methods require a type map similar to Python. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71235
* [lldb] disable thread-step-out-ret-addr-check on windowsPavel Labath2019-12-211-0/+1
| | | | I'm unable to get this test working there.
* [lldb] One more attempt to fix thread-step-out-ret-addr-check on windowsPavel Labath2019-12-211-0/+1
|
* [lldb] Force the preprocessor to run in thread-step-out-ret-addr-check.testPavel Labath2019-12-211-1/+1
| | | | It does not seem to run automatically on windows.
* [lldb] [testsuite] Fix Linux fail: Unwind/thread-step-out-ret-addr-check.testJan Kratochvil2019-12-212-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | D71372 introduced: `Unwind/thread-step-out-ret-addr-check.test` failing on Fedora 30 Linux x86_64. [lldb] Add additional validation on return address in 'thread step-out' https://reviews.llvm.org/D71372 One problem is the underscored `_nonstandard_stub` in the `.s` file but not in the LLDB command: (lldb) breakpoint set -n nonstandard_stub Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) process launch Process 21919 exited with status = 0 (0x00000000) Process 21919 launched: '/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/test/Unwind/Output/thread-step-out-ret-addr-check.test.tmp' (x86_64) (lldb) thread step-out error: invalid thread (lldb) _ Another problem is that Fedora Linux has executable stack by default and all programs indicate non-executable stack by `PT_GNU_STACK`, after fixing the underscore I was getting: (lldb) thread step-out Process 22294 exited with status = 0 (0x00000000) (lldb) _ A different approach was tried as: [lldb] Refactor thread-step-out-ret-addr-check test to use .data instead of stack variable https://reviews.llvm.org/D71789 Differential revision: https://reviews.llvm.org/D71784
* [lldb/test] Update !DIModule for isysroot renameJonas Devlieghere2019-12-201-2/+2
| | | | | The isysroot field in DIModule was renamed to sysroot but the test in LLDB wasn't updated. This fixes that.
* Re-land "[lldb/CMake] Change how we deal with optional dependencies"Jonas Devlieghere2019-12-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
* Revert "[lldb/CMake] Change how we deal with optional dependencies"Jonas Devlieghere2019-12-201-1/+0
| | | | This is failing on both the Windows and Debian bot.
* Temporarily restrict the test for D71372 to darwin till we fix it on other ↵Jim Ingham2019-12-201-1/+1
| | | | systems.
* [lldb/CMake] Change how we deal with optional dependenciesJonas Devlieghere2019-12-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
* [lldb/Lua] Implement a Simple Lua Script Interpreter PrototypeJonas Devlieghere2019-12-204-0/+8
| | | | | | | | | | | | | | | This implements a very elementary Lua script interpreter. It supports running a single command as well as running interactively. It uses editline if available. It's still missing a bunch of stuff though. Some things that I intentionally ingored for now are that I/O isn't properly hooked up (so every print goes to stdout) and the non-editline support which is not handling a bunch of corner cases. The latter is a matter of reusing existing code in the Python interpreter. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html Differential revision: https://reviews.llvm.org/D71234
* In 'thread step-out' command, only insert a breakpoint in executable memory.Jim Ingham2019-12-202-0/+37
| | | | | | | | | Previously, if the current function had a nonstandard stack layout/ABI, and had a valid data pointer in the location where the return address is usually located, data corruption would occur when the breakpoint was written. This could lead to an incorrectly reported crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts. Differential Revision: https://reviews.llvm.org/D71372
* [lldb] Fix test using lld on non-linux systemsJohannes Altmanninger2019-12-202-4/+4
|
* [LLDB] Fix address computation for inline functionJohannes Altmanninger2019-12-202-0/+34
| | | | | | | | | | | | | | | | | | | | Summary: Fixes PR41237 - SIGSEGV on call expression evaluation when debugging clang When linking multiple compilation units that define the same functions, the functions is merged but their debug info is not. This ignores debug info entries for functions in a non-executable sections; those are functions that were definitely dropped by the linker. Reviewers: spyffe, clayborg, jasonmolenda Reviewed By: clayborg Subscribers: labath, aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71487
* [lldb/test] Move script interpreter testsJonas Devlieghere2019-12-182-2/+4
| | | | | | Create a new test for lldb launched without a script interpreter and move it under a new `ScriptInterpreter` directory. Also move crashlog.test there for consistency.
* [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHONJonas Devlieghere2019-12-135-5/+5
| | | | | | | This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
* [FormatEntity] Add mangled function name supportMed Ismail Bennani2019-12-122-0/+27
| | | | | | | | | | | | | | | | | | Summary: Add `function.mangled-name` key for FormatEntity to show the mangled function names in backtraces. rdar://54088244 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71237 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* [lldb/DWARF] Fix v5 location lists for dwo filesPavel Labath2019-12-121-0/+190
| | | | | Dwo files don't have a DW_AT_loclists_base -- set one explicitly. Also, make sure we use the correct location list flavour for v5.
* [lldb] "See through" atomic types in ClangASTContextPavel Labath2019-12-121-4/+20
| | | | | | | | | | | | | | | | | Summary: This enables us to display the contents of atomic structs. Calling the removal of _Atomic "desugaring" is not fully correct as it does more than remove sugar, but it is the right thing to do for most of the things that we care about. We can change this back once we decide to support atomic types more comprehensively. Reviewers: teemperor, shafik Subscribers: jfb, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71262
* [lldb/DWARF] Add support for DW_AT_loclists_base&DW_FORM_loclistxPavel Labath2019-12-111-0/+132
| | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for DWARF5 location lists which are specified indirectly, via an index into the debug_loclists offset table. This includes parsing the DW_AT_loclists_base attribute which determines the location of this offset table, and support for new form DW_FORM_loclistx which is used in conjuction with DW_AT_location to refer to the location lists in this way. The code uses the llvm class to parse the offset information, and I've also tried to structure it similarly to how the relevant llvm functionality works. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71268
* Revert "Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support ↵Eric Christopher2019-12-102-0/+35
| | | | | | | | | multiple GDB remotes" On multiple retry this issue won't duplicate - will revisit with author if duplication works again. This reverts commit c9e0b354e2749ce7ab553974692cb35c8651a869.
* Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support multiple GDB ↵Eric Christopher2019-12-102-35/+0
| | | | | | | | | remotes This was causing a crash in opt+assert builds on linux and a follow-up message was posted. This reverts commit e81268d03e73aef4f9c7bd8ece8ad02f5b017dcf
* [lldb/Reproducers] Support multiple GDB remotesJonas Devlieghere2019-12-102-0/+35
| | | | | | | | | | | | | | | | When running the test suite with always capture on, a handful of tests are failing because they have multiple targets and therefore multiple GDB remote connections. The current reproducer infrastructure is capable of dealing with that. This patch reworks the GDB remote provider to support multiple GDB remote connections, similar to how the reproducers support shadowing multiple command interpreter inputs. The provider now keeps a list of packet recorders which deal with a single GDB remote connection. During replay we rely on the order of creation to match the number of packets to the GDB remote connection. Differential revision: https://reviews.llvm.org/D71105
* [lldb/DWARF] Switch to llvm location list parserPavel Labath2019-12-091-24/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch deletes the lldb location list parser and teaches the DWARFExpression class to use the parser in llvm instead. I have centralized all the places doing the parsing into a single GetLocationExpression function. In theory the the actual location list parsing should be covered by llvm tests, and this glue code by our existing location list tests, but since we don't have that many location list tests, I've tried to extend the coverage a bit by adding some explicit dwarf5 loclist handling and a test of the dumping code. For DWARF4 location lists this should be NFC (modulo small differences in error handling which should only show up on invalid inputs). In case of DWARF5, this fixes various missing bits of functionality, most notably, the lack of support for DW_LLE_offset_pair. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits, dblaikie Tags: #lldb Differential Revision: https://reviews.llvm.org/D71003
* [lldb] Improve/fix base address selection in location listsPavel Labath2019-12-092-0/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Lldb support base address selection entries in location lists was broken for a long time. This wasn't noticed until llvm started producing these kinds of entries more frequently with r374600. In r374769, I made a quick patch which added sufficient support for them to get the test suite to pass. However, I did not fully understand how this code operates, and so the fix was not complete. Specifically, what was lacking was the ability to handle modules which were not loaded at their preferred load address (for instance, due to ASLR). Now that I better understand how this code works, I've come to the conclusion that the current setup does not provide enough information to correctly process these entries. In the current setup the location lists were parameterized by two addresses: - the distance of the function start from the start of the compile unit. The purpose of this was to make the location ranges relative to the start of the function. - the actual address where the function was loaded at. With this the function-start-relative ranges can be translated to actual memory locations. The reason for the two values, instead of just one (the load bias) is (I think) MachO, where the debug info in the object files will appear to be relative to the address zero, but the actual code it refers to can be moved and reordered by the linker. This means that the location lists need to be "linked" to reflect the locations in the actual linked file. These two bits of information were enough to correctly process location lists which do not contain base address selection entries (and so all entries are relative to the CU base). However, they don't work with them because, in theory two base address can be completely unrelated (as can happen for instace with hot/cold function splitting, where the linker can reorder the two pars arbitrarily). To fix that, I split the first parameter into two: - the compile unit base address - the function start address, as is known in the object file The new algorithm becomes: - the location lists are processed as they were meant to be processed. The CU base address is used as the initial base address value. Base address selection entries can set a new base. - the difference between the "file" and "load" function start addresses is used to compute the load bias. This value is added to the final ranges to get the actual memory location. This algorithm is correct for non-MachO debug info, as there the location lists correctly describe the code in the final executable, and the dynamic linker can just move the entire module, not pieces of it. It will also be correct for MachO if the static linker preserves relative positions of the various parts of the location lists -- I don't know whether it actually does that, but judging by the lack of base address selection support in dsymutil and lldb, this isn't something that has come up in the past. I add a test case which simulates the ASLR scenario and demonstrates that base address selection entries now work correctly here. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70532
* [lldb] Support for DWARF-5 atomic typesRaphael Isemann2019-12-091-0/+104
| | | | | | | | | | | | | | | | | Summary: This patch adds support for atomic types (DW_TAG_atomic_type) to LLDB. It's mostly just filling out all the switch-statements that didn't implement Atomic case with the usual boilerplate. Thanks Pavel for writing the test case. Reviewers: labath, aprantl, shafik Reviewed By: labath Subscribers: jfb, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71183
* [lldb/Reproducer] Disable test on Windows to unblock the bot.Jonas Devlieghere2019-12-061-0/+1
| | | | http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja
* [lldb/DWARF] Fix DW_AT_addr_base & DW_AT_low_pc interactionPavel Labath2019-12-061-0/+106
| | | | | | | | | | | | | | | | In DWARF5 DW_AT_low_pc (and DW_AT_entry_pc, and possibly others) can use DW_FORM_addrx to refer to the address indirectly. This means we need to have processed the DW_AT_addr_base attribute before we can do anything with these. Since we were processing the unit attributes serially, this created a problem in cases where the DW_AT_addr_base comes after DW_AT_low_pc -- we would end up computing the wrong unit base address, which also corrupted any values which later depended on that (for instance range lists). Clang currently always emits DW_AT_addr_base last. The fix is simple -- process DW_AT_addr_base first, regardless of its position in the attribute list.
* [lldb/DWARF] Fix DW_AT_rnglists_base handling for dwo filesPavel Labath2019-12-061-0/+156
| | | | | | | | | | the value of DW_AT_rnglists_base of the skeleton unit is for that unit alone (e.g. used in DW_AT_ranges of the unit DIE) and should not apply to the split unit. The split unit has a hardcoded range list base value -- we should initialize range list code whenever we detect a nonempty debug_rnglists.dwo section.
* [lldb/DWARF] Switch to llvm debug_rnglists parserPavel Labath2019-12-051-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Our rnglist support was working only for the trivial cases (one CU), because we only ever parsed one contribution out of the debug_rnglists section. This means we were never able to resolve range lists for the second and subsequent units (DW_FORM_sec_offset references came out blang, and DW_FORM_rnglistx references always used the ranges lists from the first unit). Since both llvm and lldb rnglist parsers are sufficiently self-contained, and operate similarly, we can fix this problem by switching to the llvm parser instead. Besides the changes which are due to variations in the interface, the main thing is that now the range list object is a member of the DWARFUnit, instead of the entire symbol file. This ensures that each unit can get it's own private set of range list indices, and is consistent with how llvm's DWARFUnit does it (overall, I've tried to structure the code the same way as the llvm version). I've also added a test case for the two unit scenario. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71021
OpenPOWER on IntegriCloud