summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* [LLDB] Replacing use of ul suffix in GetMaxU64Bitfield since it not ↵shafik2019-12-052-12/+31
| | | | | | | | 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-0517-134/+149
| | | | | | | | | | | | | | | | | | | | | | 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-059-231/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-052-41/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Don't put compile unit name into the support file list and support ↵Pavel Labath2019-12-055-45/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARF5 line tables Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954
* Reland "[LiveDebugValues] Introduce entry values of unmodified params"Djordje Todorovic2019-12-053-16/+60
| | | | Relanding this after resolving the cause of the test failure.
* Avoid triple corruption while merging core infoMuhammad Omair Javaid2019-12-052-1/+36
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a bug where when target triple created from elf information is arm-*-linux-eabihf and platform triple is armv8l-*-linux-gnueabihf. Merging both triple results in armv8l--unknown-unknown. This happens because we order a triple update while calling CoreUpdated and CoreUpdated creates a new triple with no vendor or environment information. Making sure we do not update triple and just update to more specific core fixes the issue. Reviewers: labath, jasonmolenda, clayborg Reviewed By: jasonmolenda Subscribers: jankratochvil, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70155
* Add a default copy-assignment or copy-constructor for -Wdeprecated-copy ↵Eric Christopher2019-12-042-0/+4
| | | | warnings.
* [lldb/Reproducers] Don't instrument SBFileSpec::GetPathJonas Devlieghere2019-12-041-1/+1
| | | | | This method uses a char* and length as output arguments and the reproducer instrumentation doesn't know how to deal with that (yet).
* [lldb/Reproducers] Add missing instrumentation for SBFile (2/2)Jonas Devlieghere2019-12-041-3/+3
| | | | Found another issue while running TestDefaultConstructorForAPIObjects.
* Clear out the python class name in OptionParsingStarted for the ↵Jim Ingham2019-12-042-2/+19
| | | | | | | | OptionGroupPythonClassWithDict options class. This value was hanging around so for instance if you made a scripted breakpoint resolver, then went to set another breakpoint, it would still think you had passed in a class name and the breakpoint wouldn't do what you expected.
* [lldb/Reproducers] Add missing instrumentation for SBFileJonas Devlieghere2019-12-042-16/+19
| | | | | This was properly captured by the instrumentation framework when running TestRunCommandInterpreterAPI.py in capture-mode.
* [lldb/Reproducers] Propagate LLDB_CAPTURE_REPRODUCER to the test suiteJonas Devlieghere2019-12-043-2/+14
|
* [lldb/Reproducers] Override capture with LLDB_CAPTURE_REPRODUCER env varJonas Devlieghere2019-12-043-0/+31
| | | | | | | | | | | | | | | | | | | | Make it possible to override reproducer capture with the LLDB_CAPTURE_REPRODUCER environment variable. The goal of this change is twofold. (1) I want to be able to enable capturing reproducers during regular test runs, both locally and on the bots. To do so I need a way to force capture. I cannot do this through the Python API, because reproducer capture must be enabled *before* the debugger initialized, which happens automatically when doing `import lldb`. (2) I want to provide an escape hatch for when reproducers are enabled by default. Downstream we have reproducer capture enabled by default in the driver. This patch solves both problems by overriding the reproducer mode based on the environment variable. Acceptable values are 0/1 and ON/OFF.
* Add parray example for lldb, vrs. *ptr@count gdb cmd.Jason Molenda2019-12-041-0/+14
|
* Add help text for parray and poarray aliases.Jason Molenda2019-12-041-4/+17
|
* Upstream debugserver arm64e support.Jason Molenda2019-12-044-4/+124
| | | | | | | | | The changes are minor; primarily debugserver needs to go through accessor functions/macros when changing pc/fp/sp/lr, and debugserver needs to clear any existing pointer auth bits from values in two cases. debugserver can fetch the number of bits used for addressing from a sysctl, and will include that in the qHostInfo reply. Update qHostInfo documentation to document it.
* [LLDB] Actually fix the win-i386-line-table.s test when executed on windowsMartin Storsjö2019-12-041-3/+3
| | | | | | | | | The previous fix attempt, in 62a635e864e0, used too much escaping for the backslashes. But instead of using regexes to match both path separator forms, remove the path altogether to unify the output from the testcase between platforms.
* [lldb] Simplify debug_{rnglists,ranges}.s testsPavel Labath2019-12-042-56/+34
| | | | Remove things irrelevant to the test.
* Change Target::FindBreakpointsByName to return Expected<vector>Joseph Tremoulet2019-12-045-18/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Fix macOS build by replacing nullptr with FileSpec()Raphael Isemann2019-12-042-2/+2
| | | | | Before we had a implicit conversion from nullptr to FileSpec which was thankfully removed.
* [lldb] Remove some (almost) unused Stream::operator<<'sPavel Labath2019-12-044-74/+5
| | | | llvm::raw_ostream provides equivalent functionality.
* [lldb] s/assertTrue/assertEqual in TestStepTarget.pyPavel Labath2019-12-041-9/+7
| | | | this improves error messages.
* [lldb] Remove FileSpec(FileSpec*) constructorPavel Labath2019-12-049-42/+21
| | | | | This constructor was the cause of some pretty weird behavior. Remove it, and update all code to properly dereference the argument instead.
* [lldb] Add test for Stream::Address and Stream::AddressRangeRaphael Isemann2019-12-041-0/+92
| | | | | I'm refactoring those functions, so we should have some tests for them before doing that.
* [lldb/Editline] Fix a -Wreturn-type warning with gccPavel Labath2019-12-041-0/+1
|
* [lldb] s/FileSpec::Equal/FileSpec::MatchPavel Labath2019-12-0419-85/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Extract single member parsing out of ↵Raphael Isemann2019-12-042-443/+490
| | | | | | | | | | | | | DWARFASTParserClang::ParseChildMembers ParseChildMembers does a few things, only one part is actually parsing a single member. This extracts the member parsing logic into its own function. This commit just moves the code as-is into its own function and forwards the parameters/ local variables to it, which means it should be NFC. The only actual changes to the code are replacing 'break's (and one very curious 'continue' that behaves like a 'break') with 'return's.
* [lldb][NFC] Migrate to raw_ostream in Module::GetDescriptionRaphael Isemann2019-12-045-14/+15
|
* [lldb][NFC] Migrate to raw_ostream in ArchSpec::DumpTripleRaphael Isemann2019-12-047-15/+15
| | | | | | | | | | | | 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-032-10/+6
| | | | | And arguably `retry_if_null` isn't really descriptive of what the flag did anyway.
* [ClangASTContext] Remove a very old hack.Davide Italiano2019-12-031-25/+0
| | | | | This was fixed in clang a while ago, and the rdar associated is now closed.
* [TypeCategory] HasLanguage() is now unused.Davide Italiano2019-12-032-8/+0
|
* [FormatManager] Provide only one variant of EnableCategory.Davide Italiano2019-12-031-11/+2
| | | | All the callers pass a single language anyway.
* [DataVisualization] Simplify. NFCI.Davide Italiano2019-12-031-2/+1
|
* [TypeCategory] Nothing passes down a list of languages.Davide Italiano2019-12-032-9/+4
| | | | | | | | | | | | 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-032-30/+82
| | | | | | | | | | | | | | | | | | | 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-035-4/+53
| | | | | | | | | | | | | | | | | | | 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] Use llvm range functions in LineTable.cppPavel Labath2019-12-031-6/+2
| | | | to avoid needing to declare iterators everywhere.
* [LLDB] Disable MSVC warning C4190: ↵Alexandre Ganea2019-12-032-0/+24
| | | | | | 'LLDBSwigPythonBreakpointCallbackFunction' has C-linkage specified, but returns UDT 'llvm::Expected<bool>' which is incompatible with C Differential Revision: https://reviews.llvm.org/D70830
* [lldb][NFC] Move Curses interface implementation to own fileRaphael Isemann2019-12-036-4051/+4106
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[LiveDebugValues] Introduce entry values of unmodified params"Djordje Todorovic2019-12-032-59/+15
| | | | This reverts commit rG4cfceb910692 due to LLDB test failing.
* [lldb][NFC] Extract searching for function SymbolContexts out of ↵Raphael Isemann2019-12-032-92/+116
| | | | | | | | | | ClangExpressionDeclMap::LookupFunction This code was just creating a new SymbolContextList with any found functions in the front and orders them by how close they are to the current frame. This refactors this code into its own function to make this more obvious. Doesn't do any other changes to the code, so this is NFC.
* [lldb] Remove all remaining tabs from TestReturnValue.pyRaphael Isemann2019-12-031-5/+5
| | | | | | I assumed this was just a single typo, but it seems we actually have a whole bunch of tabs in this file which cause Python to complain about mixing tabs and spaces.
* [lldb][NFC] Test going up/down one line in the multiline expression editorRaphael Isemann2019-12-031-0/+67
|
* Fixup 6d18e53: xfail TestShowLocationDwarf5.py properlyDiana Picus2019-12-031-1/+1
| | | | Forgot to squash this...
* [lldb] Remove tab from TestReturnValue.pyRaphael Isemann2019-12-031-1/+1
| | | | | | | | | Mixing tabs and spaces makes Python exit with this error: File "llvm/lldb/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py", line 23 return (self.getArchitecture() == "aarch64" and self.getPlatform() == "linux") ^ TabError: inconsistent use of tabs and spaces in indentation
* [lldb] Move register info "augmentation" from gdb-remote into ABIPavel Labath2019-12-035-154/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [LiveDebugValues] Introduce entry values of unmodified paramsDjordje Todorovic2019-12-032-15/+59
| | | | | | | | | | | | | | | | | | | | | The idea is to remove front-end analysis for the parameter's value modification and leave it to the value tracking system. Front-end in some cases marks a parameter as modified even the line of code that modifies the parameter gets optimized, that implies that this will cover more entry values even. In addition, extending the support for modified parameters will be easier with this approach. Since the goal is to recognize if a parameter’s value has changed, the idea at very high level is: If we encounter a DBG_VALUE other than the entry value one describing the same variable (parameter), we can assume that the variable’s value has changed and we should not track its entry value any more. That would be ideal scenario, but due to various LLVM optimizations, a variable’s value could be just moved around from one register to another (and there will be additional DBG_VALUEs describing the same variable), so we have to recognize such situation (otherwise, we will lose a lot of entry values) and salvage the debug entry value. Differential Revision: https://reviews.llvm.org/D68209
OpenPOWER on IntegriCloud