summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* TestZMMRegister: use an integer division as intendedFrederic Riss2019-04-261-2/+2
| | | | llvm-svn: 359347
* [CommandInterpreter] Remove scripting language argument. (NFC)Jonas Devlieghere2019-04-263-8/+3
| | | | | | | | | | The script language argument was passed from the debugger to the command interpreter, only to call SetScriptLanguage on the debugger again. It wasn't even used to initialize the script interpreter, because that would query the debugger again. This patch removes the needless back and forth. llvm-svn: 359346
* [ScriptInterpreter] Pass the debugger instead of the command interpreterJonas Devlieghere2019-04-2611-64/+50
| | | | | | | | | | | | | | | | As discussed in D61090, there's no good reason for the script interpreter to depend on the command interpreter. When looking at the code, it becomes clear that we mostly use the command interpreter as a way to access the debugger. Hence, it makes more sense to just pass that to the script interpreter directly. This is part 1 out of 2. I have another patch in the pipeline that changes the ownership of the script interpreter to the debugger as well, but I didn't get around to finish that today. Differential revision: https://reviews.llvm.org/D61172 llvm-svn: 359330
* Replace local utility class OnExit with llvm::scope_exit (NFC)Tatyana Krasnukha2019-04-261-17/+4
| | | | llvm-svn: 359319
* [lldb] [lit] Add register read tests for YMM registers (AVX)Michal Gorny2019-04-264-0/+145
| | | | | | Differential Revision: https://reviews.llvm.org/D61074 llvm-svn: 359304
* [lldb] [lit] Add feature flags for native CPU featuresMichal Gorny2019-04-266-1/+55
| | | | | | | | | | | | Add a new lit-cpuid tool that detects CPU features used by some of the tests, and use it to populate available_features in lit. For now, this means that the test for MM/XMM register read will be run only when the host CPU support SSE instruction set. However, this is going to make it possible to introduce additional tests relying on AVX. Differential Revision: https://reviews.llvm.org/D61073 llvm-svn: 359303
* PostfixExpression: move DWARF generator out of NativePDB internalsPavel Labath2019-04-264-183/+209
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new dwarf generator is pretty much a verbatim copy of the one in PDB. In order to write a pdb-independent test for it, I needed to write a dummy "symbol resolver", which (together with the fact that I'll need one more for breakpad-specific resolution logic) prompted me to create a more simple interface for algorithms which replace or "resolve" SymbolNodes. The resolving algorithms in NativePDB have been updated to make use of that too. I have removed a couple of NativePDB tests which weren't testing anything pdb-specific and where the tested functionality was covered by the new format-agnostic tests I have added. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D61056 llvm-svn: 359288
* Allow direct comparison of ConstString against StringRefRaphael Isemann2019-04-2616-32/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
* [TestTemplateFunction] Add a missing debug info variant.Davide Italiano2019-04-251-1/+1
| | | | llvm-svn: 359249
* Another use of the interactive lldb.debugger.Jason Molenda2019-04-251-1/+1
| | | | llvm-svn: 359240
* Two tests were using the interactive convenience variableJason Molenda2019-04-252-3/+3
| | | | | | | lldb.debugger. They should not be. <rdar://problem/50210340> llvm-svn: 359234
* [lldb] [lit] Use constexpr and better constraints in Register testsMichal Gorny2019-04-252-37/+37
| | | | | | | | | | | | Use constexpr to explicitly indicate that we're dealing with integer constants, and provoke clang to assign them straight to registers whenever possible. Adjust input constraints in %mmN tests to "rm" as using integer constants is apparently disallowed there. Also use "i" for %rN tests, as we don't want clang to accidentally clobber those general purpose registers while assigning to them (however unlikely that is). llvm-svn: 359228
* [lldb] [lit] Un-XFAIL Register/x86-64-read.test for DarwinMichal Gorny2019-04-251-1/+0
| | | | llvm-svn: 359221
* [lldb] [lit] Add tests for reading new x86_64 registersMichal Gorny2019-04-252-0/+103
| | | | | | | | | Add tests covering read operations for the general-purpose and XMM registers added in x86_64 (r8-r15 and xmm8-xmm15). Differential Revision: https://reviews.llvm.org/D61072 llvm-svn: 359210
* [lldb] [lit] Remove unnecessary array use in XMM reading testMichal Gorny2019-04-251-8/+8
| | | | | | | | | | Remove the use of 2-element array for XMM data. It is an accidental leftover from previous implementation attempt, and it is unnecessary with xmm_t. Differential Revision: https://reviews.llvm.org/D61085 llvm-svn: 359208
* Fixed typo in CompileUnit::GetImportedModules documentation [NFC]Raphael Isemann2019-04-251-1/+1
| | | | llvm-svn: 359206
* Hide stderr output from lldb-argdumperAdrian Prantl2019-04-243-31/+46
| | | | | | | | | | | | | Under very specific circumstances the default shell /bin/sh might print stuff to stderr before launching lldb-argdumper, which then confuses the JSON parser. This patch suppresses stderr output from lldb-argdumper to avoid this situation. rdar://problem/50149390 Differential Revision: https://reviews.llvm.org/D61101 llvm-svn: 359156
* Skip test introduced in r359140 on windowsFrederic Riss2019-04-241-0/+2
| | | | | | | Not sure what is or is not supposed to work on Windows and I have no way to investigate this. llvm-svn: 359145
* [SystemInitializerFull] Fix header sorting (NFC)Jonas Devlieghere2019-04-241-2/+1
| | | | | | Made some changes downstream that touched the header sorting. llvm-svn: 359141
* Fix infinite recursion when calling C++ template functionsFrederic Riss2019-04-244-3/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we encounter a templated function in the debug information, we were creating an AST that looked like this: FunctionTemplateDecl 0x12980ab90 <<invalid sloc>> <invalid sloc> foo<int> |-TemplateTypeParmDecl 0x12980aad0 <<invalid sloc>> <invalid sloc> class depth 0 index 0 T |-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern | |-TemplateArgument type 'int' | `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int' `-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern |-TemplateArgument type 'int' `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int' Note that the FunctionTemplateDecl has 2 children which are identical (as in have the same address). This is not what Clang is doing: FunctionTemplateDecl 0x7f89d206c6f8 </tmp/template.cpp:1:1, line:4:1> line:2:5 foo |-TemplateTypeParmDecl 0x7f89d206c4a8 <line:1:10, col:19> col:19 referenced typename depth 0 index 0 T |-FunctionDecl 0x7f89d206c660 <line:2:1, line:4:1> line:2:5 foo 'int (T)' | `-ParmVarDecl 0x7f89d206c570 <col:9, col:11> col:11 t1 'T' `-FunctionDecl 0x7f89d206cb60 <line:2:1, line:4:1> line:2:5 used foo 'int (int)' |-TemplateArgument type 'int' `-ParmVarDecl 0x7f89d206ca68 <col:9, col:11> col:11 t1 'int':'int' The 2 chidlren are different and actually repesent different things: the first one is the unspecialized version and the second one is specialized. (Just looking at the names shows another major difference which is that we create the parent with a name of "foo<int>" when it should be just "foo".) The fact that we have those 2 identical children confuses the ClangImporter and generates an infinite recursion (reported in https://llvm.org/pr41473). We cannot create the unspecialized version as the debug information doesn't contain a mapping from the template parameters to their use in the prototype. This patch just creates 2 different FunctionDecls for those 2 children of the FunctionTemplateDecl. This avoids the infinite recursion and allows us to call functions. As the XFAILs in the added test show, we've still got issues in our handling of templates. I believe they are mostly centered on the fact that we create do not register "foo" as a template, but "foo<int>". This is a bigger change that will need changes to the debug information generation. I believe this change makes sense on its own. Reviewers: shafik, clayborg, jingham Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D61044 llvm-svn: 359140
* [ScriptInterpreterPython] find_first_of -> find (NFC)Jonas Devlieghere2019-04-241-1/+2
| | | | | | Follow up to r357198. llvm-svn: 359138
* add postfixexpression.cpp.Jason Molenda2019-04-241-0/+4
| | | | llvm-svn: 359130
* [EditLineTests] Call setenv() before editline is initialized.Davide Italiano2019-04-241-3/+5
| | | | llvm-svn: 359124
* [lldb] Use local definition of get_cpuid_countJoseph Tremoulet2019-04-241-1/+18
| | | | | | | | | | | | | | | | | | Summary: This is needed for gcc/cstdlib++ 5.4.0, where __get_cpuid_count is not defined in cpuid.h. Reviewers: labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61036 llvm-svn: 359120
* [DataFormatters] Adjusting libc++ std::list formatter to act better with ↵Shafik Yaghmour2019-04-243-2/+7
| | | | | | | | | | | | | pointers and references and adding a test to cover a previous related fix Summary: This previous fix https://github.com/llvm-mirror/lldb/commit/5469bda296c183d1b6bf74597c88c9ed667b3145 did not have a test since we did not have a reproducer. This is related to how formatters deal with pointers and references. The added tests both the new behavior and covers the previous bug fix as well. Differential Revision: https://reviews.llvm.org/D60588 llvm-svn: 359118
* Kill modify-python-lldb.pyPavel Labath2019-04-244-191/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After the last round of cleanups, this script was almost a no-op. The only piece of functionality that remained was the one which tried to make the swig-generated function signatures more pythonic. The "tried" part is important here, as it wasn't doing a really good job and the end result was not valid python nor c (e.g., SetExecutable(SBAttachInfo self, str const * path)). Doing these transformations another way is not possible, as these signatures are generated by swig, and not present in source. However, given that this is the only reason why we need a swig post-process step, and that the current implementation is pretty sub-optimal, this patch simply abandons the signature fixup idea, and chooses to simplify our build process instead. Reviewers: amccarth, jingham, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D61000 llvm-svn: 359092
* Minor code style fix in ClangUserExpression.cpp [NFC]Raphael Isemann2019-04-241-2/+1
| | | | llvm-svn: 359089
* Shorten comment line to be below 80 characters [NFC]Raphael Isemann2019-04-241-1/+1
| | | | llvm-svn: 359087
* yamlify lit/Minidump testsPavel Labath2019-04-247-82/+173
| | | | | | Replace checked-in binaries by their yaml equivalents. llvm-svn: 359074
* PostfixExpression: move parser out of NativePDB internalsPavel Labath2019-04-246-96/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The postfix expressions in PDB and breakpad symbol files are similar enough that they can be parsed by the same parser. This patch generalizes the parser in the NativePDB plugin and moves it into the PostfixExpression file created in the previous commit (r358976). The generalization consists of treating any unrecognised token as a "symbol" node (previously these would only be created for tokens starting with "$", and other token would abort the parse). This is needed because breakpad symbols can also contain ".cfa" tokens, which refer to the frame's CFA. The cosmetic changes include: - using a factory function instead of a class for creating nodes (this is more generic as it allows the same BumpPtrAllocator to be used for other things too) - using dedicated function for parsing operator tokens instead of a DenseMap (more efficient as we don't need to create the DenseMap every time). Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny Differential Revision: https://reviews.llvm.org/D61003 llvm-svn: 359073
* [Docs] Add more redirectsJonas Devlieghere2019-04-241-1/+2
| | | | | | Found two more broken links. llvm-svn: 359063
* [Docs] Update the CI pageJonas Devlieghere2019-04-241-0/+17
| | | | | | | - Add the Sphinx bot - Add a little more info llvm-svn: 359062
* [Docs] Move external links upJonas Devlieghere2019-04-242-18/+5
| | | | | | | With a duplicate link removed and the API reference moved up, the page didn't make much sense anymore. llvm-svn: 359061
* [Docs] Fix link to C++ docsJonas Devlieghere2019-04-242-2/+3
| | | | | | ... and add a redirect for the old URL. llvm-svn: 359052
* Lock accesses to OptionValueFileSpecList objectsFrederic Riss2019-04-2313-30/+56
| | | | | | | | | | | | | | | | | | | | | | | | Before a Debugger gets a Target, target settings are routed to a global set of settings. Even without this, some part of the LLDB which exist independently of the Debugger object (the Module cache, the Symbol vendors, ...) access directly the global default store for those settings. Of course, if you modify one of those global settings while they are being read, bad things happen. We see this quite a bit with FileSpecList settings. In particular, we see many cases where one debug session changes target.exec-search-paths while another session starts up and it crashes when one of those accesses invalid FileSpecs. This patch addresses the specific FileSpecList issue by adding locking to OptionValueFileSpecList and never returning by reference. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60468 llvm-svn: 359028
* [Reproducers] Limit logging to calls that cross the API boundary.Jonas Devlieghere2019-04-232-101/+93
| | | | | | | | | | | | | | | | | | | | We recently moved API logging into the instrumentation macros. This made that logging is now consistent and abstracted behind a macro for every API functions, independent of the reproducers. It also means we have a lot more output. While this is a good thing, it also meant a lot more noise in the log, from things that aren't always equally interesting, such as the copy constructor for example. To improve usability, we should increase the signal-to-noise ratio. I propose to achieve this by only logging API functions that cross the API boundary. This is a divergence of what we had before, where a select number of functions were logged, irregardless of the API boundary, a concept that was introduced for the reproducers. However, I believe this is in line with the purpose of the API log. Differential revision: https://reviews.llvm.org/D60984 llvm-svn: 359016
* Revert "[EditLineTest] Not always TERM is available, e.g. on some bots."Davide Italiano2019-04-231-13/+3
| | | | | | | This was a speculative fix trying to placate some bots, but it's ultimately just a bot configuration problem and not a code problem. llvm-svn: 359011
* [Docs] Add missing leading slashJonas Devlieghere2019-04-231-5/+5
| | | | llvm-svn: 359005
* [Docs] Add 301 redirects for old URLsJonas Devlieghere2019-04-232-0/+8
| | | | llvm-svn: 359004
* Move postfix expression code out of the NativePDB pluginPavel Labath2019-04-232-233/+246
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The NativePDB plugin contains code to convert "programs" describing the layout of function frames into dwarf (for easier interaction with the rest of lldb). This functionality is useful for the Breakpad plugin too, as it contains the same kind of expressions (because breakpad info is generated from pdb files). In this patch, I move the core classes of this code into a common place, where it can be used from both files. Previously, these were the details of the implementation, but here I am exposing them (instead of just a single "string->string" conversion function), as breakpad will need to use these in a slightly different way. The reason for that is that breakpad files generated from dwarf expressions use a slightly different syntax, although most of the core code can be reused with a bit of thought. This is also the reason why I am not moving the parsing or dwarf generation bits, as they will need to be generalized a bit before they're usable for both scenarios. This patch should be NFC, modulo renaming the moved entities to more neutral names. The reason I am moving this to the "Symbol" library, is because both customers will be "Symbol"Files, and also the unwinding code lives in the Symbol library. From a purely dependency standpoint this code will probably be standalone, and so it could be moved all the way to Utility, but that seems too low for this kind of functionality. Reviewers: jasonmolenda, amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D60599 llvm-svn: 358976
* modify-python-lldb: Remove \a-removing codePavel Labath2019-04-235-23/+19
| | | | | | instead, remove \a directly from the interface files. llvm-svn: 358967
* FuncUnwinders: remove "current_offset" from function argumentsPavel Labath2019-04-239-117/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This argument was added back in 2010 (r118882) to support the ability to unwind from functions whose eh_frame entry does not cover the entire range of the function. However, due to the caching happening in FuncUnwinders, this solution is very fragile. FuncUnwinders will cache the plan it got from eh_frame regardless of the value of the current_offset, so our ability to unwind from a given function depended what was the value of "current_offset" the first time that this function was called. Furthermore, since the "image show-unwind" command did not know what's the right offset to pass, this created an unfortunate situation where "image show-unwind" would show no valid plans for a function, even though they were available and being used. In this patch I implement the feature slightly differently. Instead of giving just a base address to the eh_frame unwinder, I give it the entire range we are interested in. Then, I change the unwinder to return the first plan that covers (even partially) that range. This way even a partial plan will be returned, regardless of the address in the function where we are stopped at. This solution is still not 100% correct, as it will not handle a function which is covered by two independent fde entries. However, I don't expect anybody will write this kind of functions, and this wasn't handled by the previous implementation either. If this is ever needed in the future. The eh_frame unwinder can be extended to return "composite" unwind plans created by merging sevelar fde entries. I also create a test which triggers this scenario. As doing this is virtually impossible without hand-written assembly, the test only works on x86 linux. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60829 llvm-svn: 358964
* UnwindPlan: pretty-print dwarf expressionsPavel Labath2019-04-233-4/+62
| | | | | | | | | | | | | | | | Summary: Previously we were printing the dwarf expressions in unwind rules simply as "dwarf-expr". This patch uses the existing dwarf-printing capabilities in lldb to enhance this dump output, and print the full decoded dwarf expression. Reviewers: jasonmolenda, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D60949 llvm-svn: 358959
* yamlify TestMiniDumpUUID binariesPavel Labath2019-04-2319-34/+183
| | | | | | | | | | | | | | Summary: Instead of checking in raw minidump binaries, check in their yaml form, and call yaml2obj in the test. Reviewers: clayborg Subscribers: javed.absar, lldb-commits Differential Revision: https://reviews.llvm.org/D60948 llvm-svn: 358957
* One small tweak to LocateExecutableScriptingResources - IJason Molenda2019-04-231-2/+2
| | | | | | | | | was still stat'ing the possibly-dSYM FileSpec before I (more cheaply) checked the filepath for telltale dSYM components. <rdar://problem/50086007> llvm-svn: 358939
* Add a small check to PlatformDarwin::LoadScriptingResourceForModuleJason Molenda2019-04-231-3/+6
| | | | | | | | | | | | | | | | | which reads the python files in a dSYM bundle, to check that the SymbolFile is actually a dSYM bundle filepath; delay any fetching of the ScriptInterpreter until after we've done that check. When debugging a binary without a dSYM on darwin systems, the SymbolFile we fetch is actually the ObjectFile -- so we would do an unnecessary trip into Python land and stat around the filesystem looking for a python file to read in. There's no reason to do any of this unless the SymbolFile's file path includes the .dSYM bundle telltale path components. <rdar://problem/50065315> llvm-svn: 358938
* Fix a bug in my change to ModulesDidLoad in r357955.Jason Molenda2019-04-221-5/+3
| | | | | | | | | | | | | In the process of hoisting the LoadScriptingResourceForModule out of Target::ModuleAdded and into Target::ModulesDidLoad, I had ModulesDidLoad fetching the Target's entire image list and look for scripting resources in those -- instead of only looking for scripting resources in the modules that had been added to the target's image list. <rdar://problem/50065315> llvm-svn: 358929
* [Docs] Move API docs to the front pageJonas Devlieghere2019-04-222-6/+7
| | | | | | | | | | | This moves the links to the C++ and Python API docs up to the main page. As of now the links are still broken [1], but at least this will prevent the additional frustration of searching for the links only to find out they're broken. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-April/014992.html llvm-svn: 358928
* Rename C++ TestGlobalVariables.py to have a distinct name from C version.Adrian Prantl2019-04-221-0/+0
| | | | llvm-svn: 358924
* [EditLineTest] Not always TERM is available, e.g. on some bots.Davide Italiano2019-04-221-3/+13
| | | | llvm-svn: 358918
OpenPOWER on IntegriCloud