summaryrefslogtreecommitdiffstats
path: root/lldb/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb][NFC] Replace ClangASTImporter's use of map/set with SmallPtrSet and ↵Raphael Isemann2019-12-161-5/+5
| | | | | | | | DenseMap We have several pointer->pointer mappings in the ClangASTImporter implemented using STL data structures. This moves these variables to the appropriate LLVM data structures that are intended for mapping pointers.
* [lldb] Remove RTTI in ClangExternalASTSourceCommon based on a global map of ↵Raphael Isemann2019-12-151-3/+11
| | | | | | | | | | | | | | | | | | | | | | known instances Summary: Currently we do our RTTI check for ClangExternalASTSourceCommon by using this global map of ClangExternalASTSourceCommon where every instance is registering and deregistering itself on creation/destruction. Then we can do the RTTI check by looking up in this map from ClangASTContext. This patch removes this whole thing and just adds LLVM-style RTTI support to ClangExternalASTSourceCommon which is possible with D71397. Reviewers: labath, aprantl Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71398
* [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHONJonas Devlieghere2019-12-131-1/+1
| | | | | | | This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
* [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_POSIXJonas Devlieghere2019-12-131-1/+2
| | | | | Rename LLDB_DISABLE_POSIX to LLDB_ENABLE_POSIX and use cmakedefine01 for consistency.
* [lldb][NFC] Make metadata tracking type safeRaphael Isemann2019-12-132-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: LLDB associates additional information with Types and Declarations which it calls ClangASTMetadata. ClangASTMetadata is stored by the ClangASTSourceCommon which is implemented by having a large map of `void *` keys to associated `ClangASTMetadata` values. To make this whole mechanism even unsafer we also decided to use `clang::Decl *` as one of pointers we throw in there (beside `clang::Type *`). The Decl class hierarchy uses multiple inheritance which means that not all pointers have the same address when they are implicitly converted to pointers of their parent classes. For example `clang::Decl *` and `clang::DeclContext *` won't end up being the same address when they are implicitly converted from one of the many Decl-subclasses that inherit from both. As we use the addresses as the keys in our Metadata map, this means that any implicit type conversions to parent classes (or anything else that changes the addresses) will break our metadata tracking in obscure ways. Just to illustrate how broken this whole mechanism currently is: ```lang=cpp // m_ast is our ClangASTContext. Let's double check that from GetTranslationUnitDecl // in ClangASTContext and ASTContext return the same thing (one method just calls the other). assert(m_ast->GetTranslationUnitDecl() == m_ast->getASTContext()->getTranslationUnitDecl()); // Ok, both methods have the same TU*. Let's store metadata with the result of one method call. m_ast->SetMetadataAsUserID(m_ast->GetTranslationUnitDecl(), 1234U); // Retrieve the same Metadata for the TU by using the TU* from the other method... which fails? EXPECT_EQ(m_ast->GetMetadata(m_ast->getASTContext()->getTranslationUnitDecl())->GetUserID(), 1234U); // Turns out that getTranslationUnitDecl one time returns a TranslationUnitDecl* but the other time // we return one of the parent classes of TranslationUnitDecl (DeclContext). ``` This patch splits up the `void *` API into two where one does the `clang::Type *` tracking and one the `clang::Decl *` mapping. Type and Decl are disjoint class hierarchies so there is no implicit conversion possible that could influence the address values. I had to change the storing of `clang::QualType` opaque pointers to their `clang::Type *` equivalents as opaque pointers are already `void *` pointers to begin with. We don't seem to ever set any qualifier in any of these QualTypes to this conversion should be NFC. Reviewers: labath, shafik, aprantl Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71409
* [Target] Remove Target::GetScratchClangASTContextAlex Langford2019-12-122-2/+15
| | | | | | | Target doesn't really need to know about ClangASTContext more than any other TypeSystem. We can create a method ClangASTContext::GetScratch for anything who needs a ClangASTContext specifically instead of just a generic TypeSystem.
* [FormatEntity] Add mangled function name supportMed Ismail Bennani2019-12-121-0/+1
| | | | | | | | | | | | | | | | | | 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/Host] Use cmakedefine01 for LLDB_ENABLE_TERMIOSJonas Devlieghere2019-12-122-3/+3
| | | | | | | This renames LLDB_CONFIG_TERMIOS_SUPPORTED to LLDB_ENABLE_TERMIOS. It now also uses cmakedefine01 to keep things consistent with out other optional dependencies. But more importantly it won't silently fail when you forget to include Config.h.
* [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_LIBXML2Jonas Devlieghere2019-12-122-3/+3
| | | | | | This keeps things consistent with out other optional dependencies. But more importantly it won't silently fail when you forget to include Config.h.
* [lldb/CMake] Rename LLDB_DISABLE_LIBEDIT to LLDB_ENABLE_LIBEDITJonas Devlieghere2019-12-122-4/+4
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71380
* [lldb/CMake] Rename LLDB_DISABLE_CURSES to LLDB_ENABLE_CURSESJonas Devlieghere2019-12-121-2/+2
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71377
* [lldb] Remove ClangASTMetricsRaphael Isemann2019-12-121-51/+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][NFC] Don't implement ClangASTContext::SetMetadata again as a static ↵Raphael Isemann2019-12-121-6/+1
| | | | | | | method We always have an ClangASTContext when we call this method so we might as well always call the non-static version.
* [lldb/Host] Use Host/Config.h for LibXML2 instead of a global defineJonas Devlieghere2019-12-112-2/+6
| | | | | Rename LIBXML2_DEFINED to LLDB_ENABLE_LIBXML2 and pass it through Config.h instead of a global define.
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-1113-309/+0
| | | | | | | | 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-111-1/+0
| | | | | | 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.
* Replace redundant code in LanguageCategory with templates (NFC)Adrian Prantl2019-12-101-20/+7
| | | | Differential Revision: https://reviews.llvm.org/D71296
* Do not cache hardcoded formats in FormatManagerAdrian Prantl2019-12-101-1/+2
| | | | | | | | | | | | | | 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-101-4/+4
| | | | Suggested by Adrian.
* Revert "Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support ↵Eric Christopher2019-12-102-47/+101
| | | | | | | | | 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-1/+1
| | | | | | | | | | Reviewers: aprantl, teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71305
* Temporarily revert [lldb] e81268d - [lldb/Reproducers] Support multiple GDB ↵Eric Christopher2019-12-102-101/+47
| | | | | | | | | remotes This was causing a crash in opt+assert builds on linux and a follow-up message was posted. This reverts commit e81268d03e73aef4f9c7bd8ece8ad02f5b017dcf
* [lldb/Host] Use Host/Config.h entries instead of a global define.Jonas Devlieghere2019-12-102-2/+11
| | | | | | | | | | | 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-102-47/+101
| | | | | | | | | | | | | | | | 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-103-58/+19
| | | | | | | | | | | | | | | 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] Actually enable wchar support in Editline when it is defined in the ↵Raphael Isemann2019-12-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | host config Summary: Our Editline implementation in LLDB supports using the wchar interface of Editline which should improve handling of unicode input when using Editline. At the moment we essentially just ignore unicode input and echo the escaped unicode code point (`\U1234`) to the command line (which we then also incorrectly treat as multiple characters, so console navigation is also broken afterwards). This patch just adds the include to the host config file which already contains the LLDB_EDITLINE_USE_WCHAR define to enable the Editline support (we just never included it in the file before). With this we now actually echo back unicode characters on macOS and we no longer ignore unicode input. On Linux this doesn't seem to improve the echoing back of characters but at least it fixes that we ignore unicode input. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71251
* [FormatManager] GetCandidateLanguages shouldn't know about ValueObject.Davide Italiano2019-12-091-3/+0
| | | | | | | | | | Reviewers: jingham, teemperor, JDevlieghere, aprantl Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71236
* [lldb/DWARF] Switch to llvm location list parserPavel Labath2019-12-091-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-19/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-094-1/+12
| | | | | | | | | | | | | | | | | 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][NFC] Move [SU]Int64ValueIsValidForByteSize to RegisterValueRaphael Isemann2019-12-061-29/+0
| | | | | | 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][NFC] Remove ability to pass a custom printf format to ↵Raphael Isemann2019-12-061-6/+1
| | | | | | DataExtractor::PutToLog This is luckily not used anywhere.
* [lldb] Migrate VMRange::Dump to raw_ostreamRaphael Isemann2019-12-061-5/+2
|
* [lldb][NFC] Migrate FileSpec::Dump to raw_ostreamRaphael Isemann2019-12-061-1/+1
|
* [lldb][NFC] Move Address and AddressRange functions out of Stream and let ↵Raphael Isemann2019-12-051-41/+48
| | | | | | | | | | | | | | | | | | | | | | 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
* Change Target::FindBreakpointsByName to return Expected<vector>Joseph Tremoulet2019-12-041-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Using a BreakpointList corrupts the breakpoints' IDs because BreakpointList::Add sets the ID, so use a vector instead, and update the signature to return the vector wrapped in an llvm::Expected which can propagate any error from the inner call to StringIsBreakpointName. Note that, despite the similar name, SBTarget::FindBreakpointsByName doesn't suffer the same problem, because it uses a SBBreakpointList, which is more like a BreakpointIDList than a BreakpointList under the covers. Add a check to TestBreakpointNames that, without this fix, notices the ID getting mutated and fails. Reviewers: jingham, JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70907
* [lldb] Remove some (almost) unused Stream::operator<<'sPavel Labath2019-12-041-40/+4
| | | | llvm::raw_ostream provides equivalent functionality.
* [lldb] Remove FileSpec(FileSpec*) constructorPavel Labath2019-12-041-12/+0
| | | | | This constructor was the cause of some pretty weird behavior. Remove it, and update all code to properly dereference the argument instead.
* [lldb] s/FileSpec::Equal/FileSpec::MatchPavel Labath2019-12-043-18/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The FileSpec class is often used as a sort of a pattern -- one specifies a bare file name to search, and we check if in matches the full file name of an existing module (for example). These comparisons used FileSpec::Equal, which had some support for it (via the full=false argument), but it was not a good fit for this job. For one, it did a symmetric comparison, which makes sense for a function called "equal", but not for typical searches (when searching for "/foo/bar.so", we don't want to find a module whose name is just "bar.so"). This resulted in patterns like: if (FileSpec::Equal(pattern, file, pattern.GetDirectory())) which would request a "full" match only if the pattern really contained a directory. This worked, but the intended behavior was very unobvious. On top of that, a lot of the code wanted to handle the case of an "empty" pattern, and treat it as matching everything. This resulted in conditions like: if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory()) which are nearly impossible to decipher. This patch introduces a FileSpec::Match function, which does exactly what most of FileSpec::Equal callers want, an asymmetric match between a "pattern" FileSpec and a an actual FileSpec. Empty paterns match everything, filename-only patterns match only the filename component. I've tried to update all callers of FileSpec::Equal to use a simpler interface. Those that hardcoded full=true have been changed to use operator==. Those passing full=pattern.GetDirectory() have been changed to use FileSpec::Match. There was also a handful of places which hardcoded full=false. I've changed these to use FileSpec::Match too. This is a slight change in semantics, but it does not look like that was ever intended, and it was more likely a result of a misunderstanding of the "proper" way to use FileSpec::Equal. [In an ideal world a "FileSpec" and a "FileSpec pattern" would be two different types, but given how widespread FileSpec is, it is unlikely we'll get there in one go. This at least provides a good starting point by centralizing all matching behavior.] Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: emaste, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70851
* [lldb][NFC] Migrate to raw_ostream in Module::GetDescriptionRaphael Isemann2019-12-041-1/+1
|
* [lldb][NFC] Migrate to raw_ostream in ArchSpec::DumpTripleRaphael Isemann2019-12-042-2/+2
| | | | | | | | | | | | Reviewers: labath, davide Reviewed By: davide Subscribers: clayborg, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70979
* [Process] GetLanguageRuntimes() takes an argument that's always constant.Davide Italiano2019-12-031-4/+2
| | | | | And arguably `retry_if_null` isn't really descriptive of what the flag did anyway.
* [TypeCategory] HasLanguage() is now unused.Davide Italiano2019-12-031-2/+0
|
* [FormatManager] Provide only one variant of EnableCategory.Davide Italiano2019-12-031-11/+2
| | | | All the callers pass a single language anyway.
* [TypeCategory] Nothing passes down a list of languages.Davide Italiano2019-12-031-2/+1
| | | | | | | | | | | | Summary: This should allow further simplifications, but it's a first step. Reviewers: teemperor, jingham, friss Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70983
* [EditLine] Fix RecallHistory to make it go in the right direction.Jonas Devlieghere2019-12-031-5/+10
| | | | | | | | | | | | | | | | | | | The naming used by editline for the history operations is counter intuitive to how it's used in lldb for the REPL. - The H_PREV operation returns the previous element in the history, which is newer than the current one. - The H_NEXT operation returns the next element in the history, which is older than the current one. This exposed itself as a bug in the REPL where the behavior of up- and down-arrow was inverted. This wasn't immediately obvious because of how we save the current "live" entry. This patch fixes the bug and introduces and enum to wrap the editline operations that match the semantics of lldb. Differential revision: https://reviews.llvm.org/D70932
* [lldb/Reproducer] Add version checkJonas Devlieghere2019-12-031-1/+1
| | | | | | | | | | | | | | | | | | | To ensure a reproducer works correctly, the version of LLDB used for capture and replay must match. Right now the reproducer already contains the LLDB version. However, this is purely informative. LLDB will happily replay a reproducer generated with a different version of LLDB, which can cause subtle differences. This patch adds a version check which compares the current LLDB version with the one in the reproducer. If the version doesn't match, LLDB will refuse to replay. It also adds an escape hatch to make it possible to still replay the reproducer without having to mess with the recorded version. This might prove useful when you know two versions of LLDB match, even though the version string doesn't. This behavior is triggered by passing a new flag -reproducer-skip-version-check to the lldb driver. Differential revision: https://reviews.llvm.org/D70934
* [lldb] Remove unneeded semicolon in IOHandlerCursesGUIPavel Labath2019-12-031-1/+1
|
* [lldb][NFC] Move Curses interface implementation to own fileRaphael Isemann2019-12-032-37/+40
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The IOHandler class source file is currently around 4600 LOC. However only 200 of these lines are concerned with the actual IOHandler class and the rest are the implementations for Editline, IOHandlerConfirm and the Curses interface. All these large features also cause that the IOHandler (which is in Core) has a large set of dependencies on other parts of LLDB. This patch splits out the code for the curses interface into its own file. This way the simple IOHandler code is no longer buried in-between much larger functionalities. Next up is splitting out the other IOHandlers into their own files and then move them to more appropriate parts of LLDB. Reviewers: labath, clayborg, JDevlieghere Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70946
* [lldb] Move register info "augmentation" from gdb-remote into ABIPavel Labath2019-12-031-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously the ABI plugin exposed some "register infos" and the gdb-remote code used those to fill in the missing bits. Now, the "filling in" code is in the ABI plugin itself, and the gdb-remote code just invokes that. The motivation for this is two-fold: a) the "augmentation" logic is useful outside of process gdb-remote. For instance, it would allow us to avoid repeating the register number definitions in minidump code. b) It gives more implementation freedom to the ABI classes. Now that these "register infos" are essentially implementation details, classes can use other methods to obtain dwarf/eh_frame register numbers -- for instance they can consult llvm MC layer. Since the augmentation code was not currently tested anywhere, I took the opportunity to create a simple test for it. Reviewers: jasonmolenda, clayborg, tatyana-krasnukha Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70906
OpenPOWER on IntegriCloud