summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
...
* Speed up accelerator table lookupsAdrian Prantl2019-10-101-3/+24
| | | | | | | | | | | | | | | | | | | When debugging a large program like clang and doing "frame variable *this", the ValueObject pretty printer is doing hundreds of scoped FindTypes lookups. The ones that take longest are the ones where the DWARFDeclContext ends in something like ::Iterator which produces many false positives that need to be filtered out *after* extracting the DIEs. This patch demonstrates a way to filter out false positives at the accerator table lookup step. With this patch lldb clang-10 -o "b EmitFunctionStart" -o r -o "f 2" -o "fr v *this" -b -- ... goes (in user time) from 5.6s -> 4.8s or (in wall clock) from 6.9s -> 6.0s. Differential Revision: https://reviews.llvm.org/D68678 llvm-svn: 374401
* Implement serializing scripted breakpoints and their extra args.Jim Ingham2019-10-103-34/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D68750 llvm-svn: 374394
* [lldb] Add log output for the support files we pass to the ↵Raphael Isemann2019-10-101-0/+11
| | | | | | | | | | | CppModuleConfiguration CppModuleConfiguration is the most likely point of failure when we have weird setups where we fail to load a C++ module. With this logging it should be easier to figure out why we can't find a valid configuration as the configuration only depends on the list of file paths. llvm-svn: 374350
* Fix the unwinding plan augmentation from x86 assemblyPavel Labath2019-10-101-16/+15
| | | | | | | | | | | | | | | | | | Unwind plan augmentation should compute the plan row at offset x from the instruction before offset x, but currently we compute it from the instruction at offset x. Note that this behavior is a regression introduced when moving the x86 assembly inspection engine to its own file (https://github.com/llvm/llvm-project/commit/1c9858b298d79ce82c45a2954096718b39550109#diff-375a2be066db6f34bb9a71442c9b71fcL913); the original version handled this properly by copying the previous instruction out before advancing the instruction pointer. The relevant bug with more info is here: https://bugs.llvm.org/show_bug.cgi?id=43561 Differential Revision: https://reviews.llvm.org/D68454 Patch by Jaroslav Sevcik <jarin@google.com>. llvm-svn: 374342
* File: Handle more cases in GetOptionsFromModePavel Labath2019-10-101-9/+11
| | | | | | | | | | The "b" (binary) flag is meaningless most of the time, but the relevant standars allow it. The standards permit one to spell it both as "r+b" and "rb+", so handle both cases. This fixes TestFileHandle.test_binary_inout with python2. llvm-svn: 374331
* [Windows] Introduce a switch for the `lldb-server` mode on WindowsAleksandr Urakov2019-10-101-6/+17
| | | | | | | | | | | | | | | | | | | Summary: This patch introduces a switch, based on the environment variable `LLDB_USE_LLDB_SERVER`, to determine whether to use the `ProcessWindows` plugin (the old way) or the `lldb-server` way for debugging on Windows. Reviewers: labath, amccarth, asmith, stella.stamenova Reviewed By: labath, amccarth Subscribers: mstorsjo, abidh, JDevlieghere, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D68258 llvm-svn: 374325
* [lldb][NFC] Remove strange bool parameter from Searcher::SearchCallbackRaphael Isemann2019-10-1013-55/+38
| | | | | | | | | | | | | | | | | | | Summary: The SearchCallback has a bool parameter that we always set to false, we never use in any callback implementation and that also changes its name from one file to the other (either `containing` and `complete`). It was added in the original LLDB check in, so there isn't any history what this was supposed to be, so let's just remove it. Reviewers: jingham, JDevlieghere, labath Reviewed By: jingham, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68696 llvm-svn: 374313
* [lldb] Fix out of bounds read in DataExtractor::GetCStr and add unit test ↵Raphael Isemann2019-10-101-19/+18
| | | | | | | | | | | | | | | | | | | | | | | | that function. Summary: The `if (*cstr_end == '\0')` in the previous code checked if the previous loop terminated because it found a null terminator or because it reached the end of the data. However, in the case that we hit the end of the data before finding a null terminator, `cstr_end` points behind the last byte in our data and `*cstr_end` reads the memory behind the array (which may be uninitialised) This patch just rewrites that function use `std::find` and adds the relevant unit tests. Reviewers: labath Reviewed By: labath Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68773 llvm-svn: 374311
* [lldb][NFC] Use llvm::all_of instead of std::all_of in CppModuleConfigurationRaphael Isemann2019-10-101-3/+3
| | | | llvm-svn: 374307
* [lldb][NFC] Use unique_ptr in DiagnosticManager to express ownershipRaphael Isemann2019-10-102-6/+7
| | | | llvm-svn: 374289
* Set eRegisterKindEHFrame register numbers for 32 bit ARM register contexts ↵Greg Clayton2019-10-092-11/+33
| | | | | | | | | | in minidumps Stack unwinding was sometimes failing when trying to unwind stacks in 32 bit ARM. I discovered this was because the EH frame register numbers were not set. This patch fixes this issue and adds a unit test to verify this doesn't regress. Differential Revision: https://reviews.llvm.org/D68088 llvm-svn: 374246
* Fix a crasher due to an assert when two files have the same UUID but ↵Greg Clayton2019-10-091-13/+31
| | | | | | | | | | | | | | | | different paths. Summary: The PlaceholderObjectFile has an assert in SetLoadAddress that fires if "m_base == value" is not true. To avoid this, we create check that the base address matches, and if it doesn't we clear the module that was found using the UUID so that we create a new PlaceholderObjectFile. Added a test to cover this issue. Reviewers: labath, aadsm, dvlahovski Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68106 llvm-svn: 374242
* remove a smattering of isolated, unnecessary uses of FILE*Lawrence D'Anna2019-10-093-13/+11
| | | | | | | | | | | | | | | | | | Summary: There a a few call sites that use FILE* which are easy to fix without disrupting anything else. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: JDevlieghere, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68444 llvm-svn: 374239
* SBFile support in SBCommandReturnObjectLawrence D'Anna2019-10-094-12/+80
| | | | | | | | | | | | | | | | | | Summary: This patch add SBFile interfaces to SBCommandReturnObject, and removes the internal callers of its FILE* interfaces. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68434 llvm-svn: 374238
* [Reproducer] Add convenience methods IsCapturing and IsReplaying.Jonas Devlieghere2019-10-091-3/+3
| | | | | | | Add convenience methods to the Reproducer class for when you don't need access to the generator and the loader. llvm-svn: 374236
* [LLDB] Fix for regression of test 'TestDataFormatterInvalidStdUniquePtr.py' ↵Cameron Desrochers2019-10-093-5/+7
| | | | | | | | introduced in r374195 Differential Revision: https://reviews.llvm.org/D68641 llvm-svn: 374231
* allow arbitrary python streams to be converted to SBFileLawrence D'Anna2019-10-092-15/+404
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds SWIG typemaps that can convert arbitrary python file objects into lldb_private::File. A SBFile may be initialized from a python file using the constructor. There are also alternate, tagged constructors that allow python files to be borrowed, and for the caller to control whether or not the python I/O methods will be called even when a file descriptor is available.I Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: zturner, amccarth, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68188 llvm-svn: 374225
* protect libedit and LLDB gui from receiving null FILE* streamsLawrence D'Anna2019-10-092-2/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: We now have valid files that will return NULL from GetStream(). libedit and the LLDB gui are the only places left that need FILE* streams. Both are doing curses-like user interaction that only make sense with a real terminal anyway, so there is no need to convert them off of their use of FILE*. But we should check for null streams before enabling these features. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: JDevlieghere, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68677 llvm-svn: 374197
* [LLDB] Fix for synthetic children memory leakCameron Desrochers2019-10-097-35/+64
| | | | | | | | The lifetime of a ValueObject and all its derivative ValueObjects (children, clones, etc.) is managed by a ClusterManager. These objects are only destroyed when every shared pointer to any of the managed objects in the cluster is destroyed. This means that no object in the cluster can store a shared pointer to another object in the cluster without creating a memory leak of the entire cluster. However, some of the synthetic children front-end implementations do exactly this; this patch fixes that. Differential Revision: https://reviews.llvm.org/D68641 llvm-svn: 374195
* Remove obsolete parameter.Adrian Prantl2019-10-091-1/+0
| | | | llvm-svn: 374185
* Remove the is_mangled flag from Mangled and SymbolAdrian Prantl2019-10-099-37/+14
| | | | | | | | | | | | | | | Testing whether a name is mangled or not is extremely cheap and can be done by looking at the first two characters. Mangled knows how to do it. On the flip side, many call sites that currently pass in an is_mangled determination do not know how to correctly do it (for example, they leave out Swift mangling prefixes). This patch removes this entry point and just forced Mangled to determine the mangledness of a string itself. Differential Revision: https://reviews.llvm.org/D68674 llvm-svn: 374180
* Unify the two CRC implementationsHans Wennborg2019-10-091-5/+3
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* [lldb] Don't crash when the ASTImporter produces diagnostics but instead log ↵Raphael Isemann2019-10-091-39/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | them. When playing with the C++ module prototype I noticed I can get LLDB to crash by making a result type that depends on __make_integer_seq (a BuiltinTemplate) which is not supported by the ASTImporter yet. This causes the ASTImporter to emit a diagnostic when copying the type to the ScratchASTContext. As deporting the result type is done after we are done parsing and the Clang's diagnostic engine asserts that it can only be used during parsing, it crashes LLDB while trying to render the diagnostic in the HandleDiagnostic method of ClangDiagnosticManagerAdapter. This patch just moves the HandleDiagnostic call to Clang behind our check that we still have a DiagnosticManager (which we remove after parsing) which prevents the assert from firing. We also shouldn't ignore such diagnostics, so I added a log statement for them. There doesn't seem to way to test this as these diagnostic only happen when we copy a node that's not supported by the ASTImporter which should never happen once we can copy everything with the ASTImporter, so every test case we add here will eventually become invalid. (Note that most of this diff is just whitespace changes as we now use an early exit instead of a huge 'if' block). llvm-svn: 374145
* Explicitly set entry point arch when it's thumb [Second Try]Antonio Afonso2019-10-081-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
* Revert Trust the arange accelerator tables in dSYMsAdrian Prantl2019-10-081-13/+7
| | | | | | | This reverts r374117 (git commit 6399db2f6fd64fa250093368be40eb5ae3af513b) while inspecting bot breakage. llvm-svn: 374121
* Trust the arange accelerator tables in dSYMsAdrian Prantl2019-10-081-7/+13
| | | | | | | | | | | | | | | | When ingesting aranges from a dSYM it makes sense to always trust the contents of the accelerator table since it always comes from dsymutil. According to Instruments, skipping the decoding of all CU DIEs to get at the DW_AT_ranges attribute removes ~3.5 seconds from setting a breakpoint by file/line when debugging clang with a dSYM. Interestingly on the wall clock the speedup is less noticeable, but still present. rdar://problem/56057688 Differential Revision: https://reviews.llvm.org/D68655 llvm-svn: 374117
* StopInfo/Mach: Delete PPC supportVedant Kumar2019-10-081-103/+0
| | | | | | | | | LLDB appears to have at least partial support for PPC, but PPC on Mach isn't a thing AFAIK. Differential Revision: https://reviews.llvm.org/D68661 llvm-svn: 374114
* Add test coverage to printing of enums and fix display of unsigned valuesFrederic Riss2019-10-081-6/+9
| | | | | | | | | | | | | | | TestCPP11EnumTypes.py should have covered all our bases when it comes to typed enums, but it missed the regression introduced in r374066. The reason it didn't catch it is somewhat funny: the test was copied over from another test that recompiled a source file with a different base type every time, but neither the test source nor the python code was adapted for testing enums. As a result, this test was just running 8 times the exact same checks on the exact same binary. This commit fixes the coverage and addresses the issue revealed by the new tests. llvm-svn: 374108
* StopInfo/Mach: Use early-exits, reflow messy comments, NFCIVedant Kumar2019-10-081-494/+481
| | | | llvm-svn: 374106
* [Reproducer] Don't isntrument methods that get called from the signal handler.Jonas Devlieghere2019-10-081-5/+4
| | | | | | | | | | | | | | LLDB's signal handlers call SBDebugger methods, which themselves try to be really careful about not doing anything non-signal safe. The Reproducer record macro is not careful though, and does unsafe things which potentially caused LLDB to crash. Given that these methods are not particularly interesting I've swapped the RECORD macros with DUMMY ones, so that we still register the API boundary but don't do anything non-signal safe. Thanks Jim for figuring this one out! llvm-svn: 374104
* Fix sign extension handling in DumpEnumValueFrederic Riss2019-10-081-0/+1
| | | | | | | | | | | | When an enumerator has an unsigned type and its high bit set, the code introduced in r374067 would fail to match it due to a sign extension snafu. This commit fixes this aspec of the code and should fix the bots. I think it's not a complete fix though, I'll add more test coverage and additional tweaks in a follow-up commit. llvm-svn: 374095
* exception handling in PythonDataObjects.Lawrence D'Anna2019-10-082-36/+392
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Python APIs nearly all can return an exception. They do this by returning NULL, or -1, or some such value and setting the exception state with PyErr_Set*(). Exceptions must be handled before further python API functions are called. Failure to do so will result in asserts on debug builds of python. It will also sometimes, but not usually result in crashes of release builds. Nearly everything in PythonDataObjects.h needs to be updated to account for this. This patch doesn't fix everything, but it does introduce some new methods using Expected<> return types that are safe to use. split off from https://reviews.llvm.org/D68188 Reviewers: JDevlieghere, jasonmolenda, labath, zturner Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68547 llvm-svn: 374094
* ObjectFileMachO: Replace std::map with llvm::DenseMap (NFC)Adrian Prantl2019-10-081-18/+10
| | | | | | | | This makes parsing the symbol table of clang marginally faster. (Hashtable versus tree). Differential Revision: https://reviews.llvm.org/D68605 llvm-svn: 374084
* Replace regex match with rfind (NFCish)Adrian Prantl2019-10-081-16/+15
| | | | | | | | | | This change is mostly performance-neutral since our regex engine is fast, but it's IMHO slightly more readable. Also, matching matching parenthesis is not a great match for regular expressions. Differential Revision: https://reviews.llvm.org/D68609 llvm-svn: 374082
* Replace static const StringRef with StringRef (NFC)Adrian Prantl2019-10-083-16/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D68597 llvm-svn: 374081
* Remove constructor and unused method (NFC).Adrian Prantl2019-10-081-15/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68595 llvm-svn: 374080
* Revert "[platform process list] add a flag for showing the processes of all ↵Shafik Yaghmour2019-10-083-8/+2
| | | | | | | | | | | users" This reverts commit 080f35fb875f52c924ee37ed4d56a51fe7056afa. Conflicts: packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestPlatformClient.py llvm-svn: 374077
* [lldb] Avoid resource leakKonrad Kleine2019-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before the pointer variable `args_dict` was assigned the result of an allocation with `new` and then `args_dict` is passed to `GetValueForKeyAsDictionary` which immediatly and unconditionally assigns `args_dict` to `nullptr`: ``` bool GetValueForKeyAsDictionary(llvm::StringRef key, Dictionary *&result) const { result = nullptr; ``` This caused a memory leak which was found in my coverity scan instance under CID 224753: https://scan.coverity.com/projects/kwk-llvm-project. Reviewers: jankratochvil, teemperor Reviewed By: teemperor Subscribers: teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68638 llvm-svn: 374071
* Simplify LZMA decoding by using ArrayRef::take_backKonrad Kleine2019-10-081-6/+6
| | | | | | | | | | | | | | Summary: Follow-up for D66791#inline-616303 Reviewers: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68647 llvm-svn: 374069
* Add pretty printing of Clang "bitfield" enumsFrederic Riss2019-10-081-8/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Using enumerators as flags is standard practice. This patch adds support to LLDB to display such enum values symbolically, eg: (E) e1 = A | B If enumerators don't cover the whole value, the remaining bits are displayed as hexadecimal: (E) e4 = A | 0x10 Detecting whether an enum is used as a bitfield or not is complicated. This patch implements a heuristic that assumes that such enumerators will either have only 1 bit set or will be a combination of previous values. This patch doesn't change the way we currently display enums which the above heuristic would not consider as bitfields. Reviewers: jingham, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67520 llvm-svn: 374067
* Extract and simplify DumpEnumValueFrederic Riss2019-10-081-39/+29
| | | | llvm-svn: 374066
* Revert "[lldb-server/android] Show more processes and package name when ↵Pavel Labath2019-10-081-45/+34
| | | | | | | | | necessary" This reverts r373758 because it causes several to test to be flaky (= failing ~90% of the time) on linux. llvm-svn: 374030
* Revert "ProcessInstanceInfoMatch: Don't match processes with no name if a ↵Jonas Devlieghere2019-10-081-1/+1
| | | | | | | | name match was requested" This breaks TestProcessAttach and TestHelloWorld on Darwin. llvm-svn: 374008
* [lldb] Reverts part of 61f471aHaibo Huang2019-10-081-1/+6
| | | | | | | | | | | Seems I wrongly merged an old patch. Reverts the change related to python dir for windows. FileSpec should always contain normalized path. I.e. using '/' even in windows. llvm-svn: 373998
* [MachO] Fix symbol merging during symtab parsing.Jonas Devlieghere2019-10-081-23/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The symtab parser in ObjectFileMachO has logic to coalesce debug (STAB) and non-debug symbols, based on the address and the symbol name for static (STSYM) and global symbols (GSYM) respectively. It makes the assumption that the debug variant is always encountered first. Rather than creating a second entry in the symbol table for the non-debug symbol, the latter gets merged into the existing debug symbol. This breaks when the linker emits the non-debug symbol first. We'd end up with two entries in the symbol table, each containing part of the information LLDB relies on. Indeed, commenting out the merging logic breaks the test suite spectacularly. This patch solves that problem by always parsing the debug symbols first. This guarantees that the assumption for merging holds. I'm not particularly happy with adding a lambda, but after numerous attempts this is the best solution I could come up with. The symtab parsing logic is pretty complex in that it touches a lot of things. I've experienced first hand that it's very easy to break things. I believe this approach strikes a balance between fixing the issue while limiting the risk of regressions. Differential revision: https://reviews.llvm.org/D68536 llvm-svn: 373994
* [lldb] Unifying lldb python pathHaibo Huang2019-10-073-40/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on mgorny@'s D67890 There are 3 places where python site-package path is calculated independently: 1. finishSwigPythonLLDB.py where files are written to site-packages. 2. lldb/scripts/CMakeLists.txt where site-packages are installed. 3. ScriptInterpreterPython.cpp where site-packages are added to PYTHONPATH. This change creates the path once and use it everywhere. So that they will not go out of sync. Also it provides a chance for cross compiling users to specify the right path for site-packages. Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68442 llvm-svn: 373991
* [Symbol] Remove unused method ClangASTContext::GetObjCClassNameAlex Langford2019-10-071-19/+0
| | | | llvm-svn: 373990
* Mark constructor as default and remove implementation (NFC)Adrian Prantl2019-10-071-2/+0
| | | | llvm-svn: 373968
* [MachO] Shuffle some things around in ParseSymtab (NFC)Jonas Devlieghere2019-10-071-5/+4
| | | | llvm-svn: 373954
* [gdb-remote] process properly effective uidWalter Erquinigo2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | Summary: Someone wrote SetEffectiveSetEffectiveGroupID instead of SetEffectiveUserID. After this fix, the android process list can show user names, e.g. ``` PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE ARGUMENTS ====== ====== ========== ========== ========== ========== ============================== ============================ 529 1 root 0 root 0 /sbin/ueventd ``` Reviewers: labath,clayborg,aadsm,xiaobai Subscribers: llvm-svn: 373953
OpenPOWER on IntegriCloud