summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb/CMake] Rename LLDB_DISABLE_CURSES to LLDB_ENABLE_CURSESJonas Devlieghere2019-12-124-12/+8
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71377
* [lldb/DWARF] Fix v5 location lists for dwo filesPavel Labath2019-12-122-1/+8
| | | | | 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] Remove ClangASTMetricsRaphael Isemann2019-12-123-55/+0
| | | | | | | | | | | | | | Summary: Not once have I looked at these numbers in a log and considered them useful. Also this should not have been implemented via an unguarded list of globals. Reviewers: martong, shafik Reviewed By: shafik Subscribers: rnkovacs, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71336
* [lldb] "See through" atomic types in ClangASTContextPavel Labath2019-12-121-52/+48
| | | | | | | | | | | | | | | | | 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][NFC] Don't implement ClangASTContext::SetMetadata again as a static ↵Raphael Isemann2019-12-121-7/+8
| | | | | | | method We always have an ClangASTContext when we call this method so we might as well always call the non-static version.
* [lldb/CMake] Simplify linking against cursesJonas Devlieghere2019-12-111-1/+5
| | | | | | Centralize the logic to determine what libraries to link against for curses in the CMake file where it is actually being used. Use target_include_directories instead of include_directories.
* [lldb/Host] Use Host/Config.h for LibXML2 instead of a global defineJonas Devlieghere2019-12-111-29/+30
| | | | | Rename LIBXML2_DEFINED to LLDB_ENABLE_LIBXML2 and pass it through Config.h instead of a global define.
* return-object-by-reference ("non trivial") xfail on arm64 in TestTrivialABI.pyJason Molenda2019-12-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't think this test case can be handled correctly on AAPCS64. The ABI says that the caller passes the address of the return object in x8. x8 is a caller-spilled (aka "volatile") register, and the function is not required to preserve x8 or to copy the address back into x8 on function exit like the SysV x86_64 ABI does with rax. (from aapcs64: "there is no requirement for the callee to preserve the value stored in x8") From my quick reading of ABISysV_arm64, I worry that it may actually be using the value in x8 at function exit, assuming it still has the address of the return object - if (is_return_value) { // We are assuming we are decoding this immediately after returning from // a function call and that the address of the structure is in x8 reg_info = reg_ctx->GetRegisterInfoByName("x8", 0); This will work on trivial test programs / examples, but if the function does another function call, or overwrites x8 as a scratch register, lldb will provide incorrect values to the user. ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value as unavailable so we're providing incorrect values to the user all the time. I expect my fix will be to make ABIMacOSX_arm64 flag the return value as unretrievable, unless I've misread the ABI.
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-1112-323/+14
| | | | | | | | This is a half-implemented feature that as far as we can tell was never used by anything since its original inclusion in 2014. This patch removes it to make remaining the code easier to understand. Differential Revision: https://reviews.llvm.org/D71310
* [lldb] Don't search the metadata map three times when retrieving metadataRaphael Isemann2019-12-112-7/+4
| | | | | | HasMetadata checks if our metadata map knows the given object. GetMetadata also does this check and then does another search to actually retrieve the value. This can all just be one lookup.
* [lldb][NFC] Remove dead metadata code in ClangASTSourceProxyRaphael Isemann2019-12-111-12/+0
|
* [lldb][NFC] Remove ClangExternalASTSourceCommon::g_TotalSizeOfMetadataRaphael Isemann2019-12-111-7/+0
| | | | Turns out this counter is doing literally nothing beside counting.
* [lldb/DWARF] Add support for DW_AT_loclists_base&DW_FORM_loclistxPavel Labath2019-12-115-3/+42
| | | | | | | | | | | | | | | | | | | | | | 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
* Remove unsound caching in LanguageCategoryAdrian Prantl2019-12-101-4/+0
| | | | | | | | Analogous to https://reviews.llvm.org/D71233 it is not safe to cache something that depends on the actual ValueObject in a cache then keys only off the type name. Differential Revision: https://reviews.llvm.org/D71297
* Replace redundant code in LanguageCategory with templates (NFC)Adrian Prantl2019-12-101-132/+55
| | | | Differential Revision: https://reviews.llvm.org/D71296
* [FormatManager] Move Language lookup into the obviously non-cached part (NFC)Adrian Prantl2019-12-101-16/+16
| | | | | | | | | | | | | | This refactoring makes the lookup caching easier to reason about. This has no observable effect although it does slightly change what is being cached. - Before this patch a negative lookup in the LanguageCategory would be cached, but a positive wouldn't. - After this patch LanguageCategory lookups aren't cached by FormatManager, period. (LanguageCategory has its own FormatCache for this!) Differential Revision: https://reviews.llvm.org/D71289
* Do not cache hardcoded formats in FormatManagerAdrian Prantl2019-12-101-12/+18
| | | | | | | | | | | | | | The cache in FormatCache uses only a type name as key. The hardcoded formats, synthetic children, etc inspect an entire ValueObject to determine their eligibility, which isn't modelled in the cache. This leads to bugs such as the one in this patch (where two similarly named types in different files have different hardcoded summary providers). The problem is exaggerated in the Swift language plugin due to the language's dynamic nature. rdar://problem/57756763 Differential Revision: https://reviews.llvm.org/D71233
* [DataFormatters] Change the Get() method to take a LanguageType.Davide Italiano2019-12-103-18/+18
| | | | Suggested by Adrian.
* Revert "Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support ↵Eric Christopher2019-12-109-100/+129
| | | | | | | | | multiple GDB remotes" On multiple retry this issue won't duplicate - will revisit with author if duplication works again. This reverts commit c9e0b354e2749ce7ab553974692cb35c8651a869.
* [TypeCategory] IsApplicable gets a LanguageType, not a ValueObject.Davide Italiano2019-12-101-6/+5
| | | | | | | | | | Reviewers: aprantl, teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71305
* [lldb] Add #include to appease the modules buildVedant Kumar2019-12-101-0/+1
| | | | | | | | | | | | | | | | | This #include appears to be completely unnecessary, but it does fix the following build failure: http://green.lab.llvm.org/green/job/lldb-cmake/4565/consoleText FAILED: tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLIBXML2_DEFINED -DLLDB_CONFIGURATION_RELEASE -DLLDB_USE_OS_LOG -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lldb/source/Host -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Host -Itools/lldb/source -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/include -Itools/lldb/include -Iinclude -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include -I/usr/local/Frameworks/Python.framework/Versions/3.7/include/python3.7m -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/../clang/include -Itools/lldb/../clang/include -I/usr/local/include -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/. -isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/libxml2 -Wdocumentation -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -fmodules -fmodules-cache-path=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/module.cache -fcxx-modules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -UNDEBUG -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o -MF tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o.d -o tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o -c /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Host/common/MainLoop.cpp /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Host/common/MainLoop.cpp:211:7: error: use of undeclared identifier 'ppoll' if (ppoll(read_fds.data(), read_fds.size(), nullptr, &sigmask) == -1 && ^ /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Host/common/MainLoop.cpp:336:25: error: use of undeclared identifier 'HAVE_SYS_EVENT_H' ret = pthread_sigmask(HAVE_SYS_EVENT_H ? SIG_UNBLOCK : SIG_BLOCK, ^ 2 errors generated.
* Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support multiple GDB ↵Eric Christopher2019-12-109-129/+100
| | | | | | | | | remotes This was causing a crash in opt+assert builds on linux and a follow-up message was posted. This reverts commit e81268d03e73aef4f9c7bd8ece8ad02f5b017dcf
* Fix a -Wsign-compare error around wchar_t vs unsigned int.Eric Christopher2019-12-101-1/+1
|
* [lldb/Host] Use Host/Config.h entries instead of a global define.Jonas Devlieghere2019-12-1018-20/+29
| | | | | | | | | | | As suggested by Pavel in a code review: > Can we replace this (and maybe python too, while at it) with a > Host/Config.h entry? A global definition means that one has to > recompile everything when these change in any way, whereas in > practice only a handful of files need this.. Differential revision: https://reviews.llvm.org/D71280
* [lldb/Reproducers] Support multiple GDB remotesJonas Devlieghere2019-12-109-100/+129
| | | | | | | | | | | | | | | | 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
* Replace redundant code in FormatManager and FormatCache with templates (NFC)Adrian Prantl2019-12-104-504/+124
| | | | | | | | | | | | | | | This is a preparatory patch for an upcoming bugfix. FormatManager and friends have four identical implementations of many accessor functions to deal with the four types of shared pointers in the FormatCache. This patch replaces these implementations with templates. While this patch drastically reduces the amount of source code and its maintainablity, it doesn't actually improve code size. I'd argue, this is still an improvement. rdar://problem/57756763 Differential Revision: https://reviews.llvm.org/D71231
* [lldb] Centralize type "desugaring" logic in ClangASTContextPavel Labath2019-12-101-801/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A *lot* of ClangASTContext functions contained repetitive code for "desugaring" certain kinds of clang types. This patch creates a utility function for performing this task. Right now it handles four types (auto, elaborated, paren and typedef), as these are the types that were handled everywhere. There are probably other kinds of types that could/should be added here too (TypeOf, decltype, ...), but I'm leaving that for a separate patch as doing that would not be NFC (though I'm pretty sure that adding them will not hurt, and it may in fact fix some bugs). In another patch I'd like to add "atomic" type to this list to properly display atomic structs. Since sometimes one may want to handle a certain kind of type specially (right now we have code which does that with typedefs), the Desugar function takes a "mask" argument, which can supress desugaring of certain kinds of types. Reviewers: teemperor, shafik Subscribers: jfb, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71212
* [lldb][NFC] Make g_TotalSizeOfMetadata in ClangExternalASTSourceCommon.cpp ↵Raphael Isemann2019-12-101-1/+1
| | | | | | static Clang was warning that this global should be static (which makes sense).
* [LLDB] [PECOFF] Make sure to set the address byte size in m_data after ↵Martin Storsjö2019-12-102-7/+2
| | | | | | | | | | | | | parsing headers If not set, the address byte size was implied to be the one of the host process. This allows reverting the functional change from 31087b2ae9154, since now PECOFF does the same as ELF and MachO wrt setting both byte order and address size on m_data within ParseHeader. Differential Revision: https://reviews.llvm.org/D71108
* [FormatManager] GetCandidateLanguages shouldn't know about ValueObject.Davide Italiano2019-12-092-4/+5
| | | | | | | | | | Reviewers: jingham, teemperor, JDevlieghere, aprantl Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71236
* [FormatManager] Provide a single entrypoint for GetCandidateLanguages().Davide Italiano2019-12-091-5/+1
|
* [lldb][CMake] Fix build for the case of custom libedit installationTatyana Krasnukha2019-12-091-0/+11
|
* [lldb/DWARF] Switch to llvm location list parserPavel Labath2019-12-091-261/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-093-57/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-095-1/+47
| | | | | | | | | | | | | | | | | 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
* Symbol: use elaborated types for `DataExtractor`Saleem Abdulrasool2019-12-071-3/+3
| | | | | | Use type elaborated spellings for the parameter to avoid the ambiguity between `llvm` and `lldb_private` names. This is needed for building with Visual Studio.
* Cleanup and speedup NativeRegisterContextLinux_arm64Muhammad Omair Javaid2019-12-064-160/+130
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch simplifies register accesses in NativeRegisterContextLinux_arm64 and also adds some bare minimum caching to avoid multiple calls to ptrace during a stop. Linux ptrace returns data in the form of structures containing GPR/FPR data. This means that one single call is enough to read all GPRs or FPRs. We do that once per stop and keep reading from or writing to the buffer that we have in NativeRegisterContextLinux_arm64 class. Before a resume or detach we write all buffers back. This is tested on aarch64 thunder x1 with Ubuntu 18.04. Also tested regressions on x86_64. Reviewers: labath, clayborg Reviewed By: labath Subscribers: kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D69371
* [lldb][NFC] Move [SU]Int64ValueIsValidForByteSize to RegisterValueRaphael Isemann2019-12-061-3/+31
| | | | | | These functions are an implementation detail of RegisterValue, so it doesn't make a lot of sense to implement them in a totally unrelated class.
* [lldb/DWARF] Fix DW_AT_addr_base & DW_AT_low_pc interactionPavel Labath2019-12-061-4/+13
| | | | | | | | | | | | | | | | 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][NFC] Remove ability to pass a custom printf format to ↵Raphael Isemann2019-12-061-10/+9
| | | | | | DataExtractor::PutToLog This is luckily not used anywhere.
* [lldb/DWARF] Fix DW_AT_rnglists_base handling for dwo filesPavel Labath2019-12-061-3/+5
| | | | | | | | | | 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] Migrate VMRange::Dump to raw_ostreamRaphael Isemann2019-12-063-5/+6
|
* [lldb/IRExecutionUnit] Stop searching based on demangled namesPavel Labath2019-12-061-2/+0
| | | | | | | | | | | | | | | | | | | | | Summary: This was causing problems on linux, where we'd end up calling the deleting destructor instead of a regular one (because they have the same demangled name), making a lot of mischief in the process. The only place where this was necessary (according to the test suite, at least) was to call a base structor instead of a complete one, but this is now handled in a more targeted fashion. TestCallOverriddenMethod is now re-enabled as it now passes reliably. Reviewers: teemperor, JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70722
* [lldb/DWARF] Remove DWARFDebugRangesBase abstract classPavel Labath2019-12-062-13/+4
| | | | | now that we use llvm to parse debug_rnglists, this abstraction is not useful.
* [lldb][NFC] Migrate FileSpec::Dump to raw_ostreamRaphael Isemann2019-12-0612-23/+21
|
* [lldb] NFC: less nesting in SearchFilter.cppKonrad Kleine2019-12-061-165/+170
| | | | | | | | | | | | I was working on SearchFilter.cpp and felt it a bit too complex in some cases in terms of nesting and logic flow. Reviewers: teemperor, JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71022
* [LLDB] Replacing use of ul suffix in GetMaxU64Bitfield since it not ↵shafik2019-12-051-11/+21
| | | | | | | | guarenteed to be 64 bit GetMaxU64Bitfield(...) uses the ul suffix but we require a 64 bit unsigned integer and ul could be 32 bit. So this replacing it with a explicit cast and refactors the code around it to use an early exit. Differential Revision: https://reviews.llvm.org/D70992
* [lldb][NFC] Move Address and AddressRange functions out of Stream and let ↵Raphael Isemann2019-12-0515-62/+74
| | | | | | | | | | | | | | | | | | | | | | them take raw_ostream Summary: Yet another step on the long road towards getting rid of lldb's Stream class. We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs. I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71052
* [lldb/DWARF] Switch to llvm debug_rnglists parserPavel Labath2019-12-058-230/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb/cpluspluslanguage] Add constructor substitutorPavel Labath2019-12-051-41/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds code which will substitute references to the full object constructors/destructors with their base object versions. Like all substitutions in this category, this operation is not really sound, but doing this in a more precise way allows us to get rid of a much larger hack -- matching function according to their demangled names, which effectively does the same thing, but also much more. This is a (very late) follow-up to D54074. Background: clang has an optimization which can eliminate full object structors completely, if they are found to be equivalent to their base object versions. It does this because it assumes they can be regenerated on demand in the compile unit that needs them (e.g., because they are declared inline). However, this doesn't work for the debugging scenario, where we don't have the structor bodies available -- we pretend all constructors are defined out-of-line as far as clang is concerned. This causes clang to emit references to the (nonexisting) full object structors during expression evaluation. Fun fact: This is not a problem on darwin, because the relevant optimization is disabled to work around a linker bug. Reviewers: teemperor, JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70721
OpenPOWER on IntegriCloud