summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] [PECOFF] Only use PECallFrameInfo on the one supported architectureMartin Storsjö2020-05-181-0/+3
| | | | | | | | | The RuntimeFunction struct, which PECallFrameInfo interprets, has a different layout and differnet semantics on all architectures. Differential Revision: https://reviews.llvm.org/D77000 (cherry picked from commit aa786b881fc89a2a9883bff77912f2053126f95b)
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-032-3/+3
| | | | | | | | | | | | | and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
* [LLDB] Fix the handling of unnamed bit-fields when parsing DWARFshafik2020-01-272-135/+66
| | | | | | | | We ran into an assert when debugging clang and performing an expression on a class derived from DeclContext. The assert was indicating we were getting the offsets wrong for RecordDeclBitfields. We were getting both the size and offset of unnamed bit-field members wrong. We could fix this case with a quick change but as I extended the test suite to include more combinations we kept finding more cases that were being handled incorrectly. A fix that handled all the new cases as well as the cases already covered required a refactor of the existing technique. Differential Revision: https://reviews.llvm.org/D72953 (cherry picked from commit fcaf5f6c01a09f23b948afb8c91c4dd951d4525e)
* [lldb/CommandInterpreter] Remove flag that's always true (NFC)Jonas Devlieghere2020-01-141-2/+2
| | | | | | | The 'asynchronously' argument to both GetLLDBCommandsFromIOHandler and GetPythonCommandsFromIOHandler is true for all call sites. This commit simplifies the API by dropping it and giving the baton a default argument.
* [lldb/DWARF] Move location list sections into DWARFContextPavel Labath2020-01-147-19/+29
| | | | | | These are the last sections not managed by the DWARFContext object. I also introduce separate SectionType enums for dwo section variants, as this is necessary for proper handling of single-file split dwarf.
* Expression eval lookup speedup by not returning methods in ↵Levon Ter-Grigoryan2020-01-142-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | ManualDWARFIndex::GetFunctions Summary: This change is connected with https://reviews.llvm.org/D69843 In large codebases, we sometimes see Module::FindFunctions (when called from ClangExpressionDeclMap::FindExternalVisibleDecls) returning huge amounts of functions. In current fix I trying to return only function_fullnames from ManualDWARFIndex::GetFunctions when eFunctionNameTypeFull is passed as argument. Reviewers: labath, jarin, aprantl Reviewed By: labath Subscribers: shafik, clayborg, teemperor, arphaman, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70846
* [lldb/Expression] Improve interpreter error message with a non-running targetMed Ismail Bennani2020-01-141-2/+3
| | | | | | | | | | | | | | | | | | When trying to interpret an expression with a function call, if the process hasn't been launched, the expression fails to be interpreted and the user gets the following error message: ```error: Can't run the expression locally``` This message doesn't explain why the expression failed to be interpreted, that's why this patch improves the error message that is displayed when trying to run an expression while no process is running. rdar://11991708 Differential Revision: https://reviews.llvm.org/D72510 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* [LanguageRuntime] Retire an unused member function. NFCI.Davide Italiano2020-01-134-42/+0
|
* [lldb] Fix lookup of symbols with the same address range but different bindingJan Kratochvil2020-01-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30): PASS: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325 frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243 frame #7: 0x000000000040106e a.out`_start + 46 vs. FAIL - unrecognized abort() function: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325 frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243 frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46 The extra ELF symbols are there due to Annobin (I did not investigate why this problem happened specifically since F-30 and not since F-28). It is due to: Symbol table '.dynsym' contains 2361 entries: Valu e Size Type Bind Vis Name 0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely 000000000002276e 548 FUNC GLOBAL DEFAULT abort 000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5 000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort 0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely GDB has some more complicated preferences between overlapping and/or sharing address symbols, I have made here so far the most simple fix for this case. Differential revision: https://reviews.llvm.org/D63540
* [Disassembler] Delete the VStream parameter of MCDisassembler::getInstruction()Fangrui Song2020-01-113-13/+11
| | | | | | | | | | The argument is llvm::null() everywhere except llvm::errs() in llvm-objdump in -DLLVM_ENABLE_ASSERTIONS=On builds. It is used by no target but X86 in -DLLVM_ENABLE_ASSERTIONS=On builds. If we ever have the needs to add verbose log to disassemblers, we can record log with a member function, instead of passing it around as an argument.
* [lldb/Lua] Support loading Lua modulesJonas Devlieghere2020-01-104-0/+49
| | | | | | Implements the command script import command for Lua. Differential revision: https://reviews.llvm.org/D71825
* [lldb] Remove FieldDecl stealing hack by rerouting indirect imports to the ↵Raphael Isemann2020-01-101-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | original AST Summary: This is a port of D67803 that was about preventing indirect importing to our scratch context when evaluating expressions. D67803 already has a pretty long explanation of how this works, but the idea is that instead of importing declarations indirectly over the expression AST (i.e., Debug info AST -> Expression AST -> scratch AST) we instead directly import the declaration from the debug info AST to the scratch AST. The difference from D67803 is that here we have to do this in the ASTImporterDelegate (which is our ASTImporter subclass we use in LLDB). It has the same information as the ExternalASTMerger in D67803 as it can access the ClangASTImporter (which also keeps track of where Decls originally came from). With this patch we can also delete the FieldDecl stealing hack in the ClangASTSource (this was only necessary as the indirect imports caused the creation of duplicate Record declarations but we needed the fields in the Record decl we originally found in the scratch ASTContext). This also fixes the current gmodules failures where we fail to find std::vector fields after an indirect import over the expression AST (where it seems even our FieldDecl stealing hack can't save us from). Reviewers: shafik, aprantl Reviewed By: shafik Subscribers: JDevlieghere, lldb-commits, mib, labath, friss Tags: #lldb Differential Revision: https://reviews.llvm.org/D72507
* Add missing nullptr checks.Adrian Prantl2020-01-105-26/+36
| | | | | | | | | | GetPersistentExpressionStateForLanguage() can return a nullptr if it cannot construct a typesystem. This patch adds missing nullptr checks at all uses. Inspired by rdar://problem/58317195 Differential Revision: https://reviews.llvm.org/D72413
* [lldb/DWARF] Don't automatically search dwo unit attributesPavel Labath2020-01-104-23/+7
| | | | | | | | | | | | This patch removes the code (deep inside DWARFDebugInfoEntry) which automagically returned the attributes of the dwo unit DIE when asking for the attributes of the skeleton unit. This is fairly hacky, and not consistent with how llvm DWARF parser operates. Instead, I change the code the explicitly request (via GetNonSkeletonUnit) the right unit to search (there were just two places that needed this). If it turns out we need this more often, we can create a utility function (external to DWARFUnit) for doing this.
* When reading Aux file in chunks, read consecutive byte rangesJason Molenda2020-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | qemu has a very small maximum packet size (4096) and it actually only uses half of that buffer for some implementation reason, so when lldb asks for the register target definitions, the x86_64 definition is larger than 4096/2 and we need to fetch it in two parts. This patch and test is fixing a bug in GDBRemoteCommunicationClient::ReadExtFeature when reading a target file in multiple parts. lldb was assuming that it would always get back the maximum packet size response (4096) instead of using the actual size received and asking for the next group of bytes. We now have two tests in gdb_remote_client for unique features of qemu - TestNestedRegDefinitions.py would test the ability of lldb to follow multiple levels of xml includes; I opted to create a separate TestRegDefinitionInParts.py test to test this wrinkle in qemu's gdb remote serial protocol stub implementation. Instead of combining both tests into a single test file. <rdar://problem/49537922>
* [lldb/Lua] Make lldb.debugger et al available to LuaJonas Devlieghere2020-01-094-3/+40
| | | | | | | | The Python script interpreter makes the current debugger, target, process, thread and frame available to interactive scripting sessions through convenience variables. This patch does the same for Lua. Differential revision: https://reviews.llvm.org/D71801
* [lldb/DWARF] Fix mixed v4+v5 location listsPavel Labath2020-01-097-35/+26
| | | | | | | | | | | | | | | | | | | | | | Summary: Our code was expecting that a single (symbol) file contains only one kind of location lists. This is not correct (on non-apple platforms, at least) as a file can compile units with different dwarf versions. This patch moves the deteremination of location list flavour down to the compile unit level, fixing this problem. I have also tried to rougly align the code with the llvm DWARFUnit. Fully matching the API is not possible because of how lldb's DWARFExpression lives separately from the rest of the DWARF code, but this is at least a step in the right direction. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71751
* [lldb/DWARF] Add is_dwo member to DWARFUnitPavel Labath2020-01-097-20/+19
| | | | | | | | | | | | | | | | | | | | | | Summary: A skeleton unit can easily be detected by checking the m_dwo_symbol_file member, but we cannot tell a split unit from a normal unit from the "inside", which is sometimes useful. This patch adds a m_is_dwo member to enable this, and align the code with llvm::DWARFUnit. Right now it's only used to avoid creating a split unit inside another split unit (which removes one override from SymbolFileDWARFDwo and brings us a step closer to deleting it), but my main motivation is fixing the handling of location lists in mixed v4&v5 files. This comes in a separate patch. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71750
* [lldb] Remove various dead Compare functionsAlex Langford2020-01-081-95/+0
|
* Delete dead code.Adrian Prantl2020-01-081-48/+0
| | | | https://reviews.llvm.org/D58856
* Remove extraneous spacesMed Ismail Bennani2020-01-071-1/+1
| | | | Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* [lldb][NFC] Use static_cast instead of reinterpret_cast where possibleRaphael Isemann2020-01-073-5/+3
| | | | | | | | | | | | | | Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
* [lldb][NFC] Take a llvm::Triple in ClangASTContext constructorRaphael Isemann2020-01-072-6/+2
| | | | | | This constructor is supposed to take a string representing an llvm::Triple. We might as well take a llvm::Triple here which saves us all the string conversions in the call sites and we make this more type safe.
* [lldb] Fix LLDB build after API change to printInst (D72172)Raphael Isemann2020-01-071-2/+2
| | | | | It seems in D72172 we always pass a 0 as the new default argument so let's do the same in LLDB to get the build bot running.
* [NSArray] Remove a very old and deprecated formatter.Davide Italiano2020-01-061-27/+0
| | | | Checked with the Foundation folks.
* [lldb] [Process/NetBSD] Remove unused orig_*ax useMichał Górny2020-01-061-5/+0
| | | | | | | orig_*ax logic is Linux-specific, and was never used on NetBSD. In fact, its support seems to be a dead code entirely. Differential Revision: https://reviews.llvm.org/D72195
* [lldb][NFC] Remove forward declaration for non-existent type clang::Action ↵Raphael Isemann2020-01-032-6/+2
| | | | | | | and delete references to it There is no clang::Action anymore so our forward decl for it and the obsolete pointer in the ASTStructExtractor can both go (that code anyway didn't do anything).
* [lldb/CMake] Fix variable naming in FindLibEditJonas Devlieghere2020-01-021-2/+2
| | | | | | | | | | | | The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by find_package_handle_standard_args. However this isn't valid for the package name. The argument for FOUND_VAR is "libedit_FOUND", but only "LibEdit_FOUND" and "LIBEDIT_FOUND" are valid names. This fixes all the variables set by FindLibEdit to match the desired naming scheme.
* [lldb/CMake] Use PYTHON_LIBRARIES instead of PYTHON_LIBRARYJonas Devlieghere2020-01-021-1/+1
| | | | | | PYTHON_LIBRARIES is the canonical variable set by FindPythonLibs while PYTHON_LIBRARY is an implementation detail. This replaces the uses of the latter with the former.
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-022-3/+3
| | | | | | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling. This restores 68a235d07f9e7049c7eb0c8091f37e385327ac28, e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad. The problem with the windows bot is a need for clearing the cache.
* Revert "build: reduce CMake handling for zlib"James Henderson2020-01-022-3/+3
| | | | | | | This reverts commit 68a235d07f9e7049c7eb0c8091f37e385327ac28. This commit broke the clang-x64-windows-msvc build bot and a follow-up commit did not fix it. Reverting to fix the bot.
* [lldb][NFC] Remove unused variable in DWARFASTParserClang::ParseSingleMemberRaphael Isemann2020-01-021-1/+0
|
* [lldb][NFC] Create type-safe function for creating a CompilerType from a ↵Raphael Isemann2020-01-025-13/+10
| | | | | | | | | | | | | | | | | | | | | | QualType LLDB frequently converts QualType to CompilerType. This is currently done like this: result = CompilerType(this, qual_type_var.getAsOpaquePtr()) There are a few shortcomings in this current approach: 1. CompilerType's constructor takes a void* pointer so it isn't type safe. 2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type actually belongs to the passed ClangASTContext) without expanding the TypeSystem API. 3. The logic for converting QualType->CompilerType is spread out over all of LLDB so changing it is difficult (e.g., what if we want to just pass the type ptr and not the 1type_ptr | qual_flags1 to CompilerType). This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl functions that does this conversion in a type safe way. It also adds a sanity check for Tag-based types that the type actually belongs to the current ClangASTContext (Types don't seem to know their ASTContext, so we have to workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types we construct but it's better than no sanity check).
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-012-3/+3
| | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling.
* [lldb][NFC] Simplify CompilerType constructors/destructors and fix unused ↵Raphael Isemann2020-01-011-2/+0
| | | | | | | | | variable warning CompilerType has no virtual functions and no statements in its constructors, so we can simplify this code. This also allows Clang to emit unused variable warnings for CompilerType, so I also removed one unused variable that otherwise causes -Werror builds to fail.
* [NFC] Fixes -Wrange-loop-analysis warningsMark de Wever2020-01-012-2/+2
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857
* [lldb][NFC] Simplify ClangASTContext::GetTypeForDeclRaphael Isemann2019-12-301-3/+4
| | | | Also removes the GetASTContext call from this code.
* [lldb][NFC] Delete static versions of ClangASTContext::CreateFunctionTypeRaphael Isemann2019-12-291-2/+2
| | | | We can always call the member function version of this function.
* [lldb][NFC] Remove GetASTContext call in ClangPersistentVariablesRaphael Isemann2019-12-283-27/+36
| | | | | | | | We try to build a CompilerType from the persistent decls so we need a ClangASTContext. With this patch the ClangPersistentVariables store the associated ClangASTContext of the persistent decls (which is always the scratch ClangASTContext) and no longer call GetASTContext to map back from clang::ASTContext to ClangASTContext.
* [lldb][NFC] Remove GetASTContext call in ClangDeclVendorRaphael Isemann2019-12-285-22/+20
| | | | | | | | Instead of returning NamedDecls and then calling GetASTContext to find back the ClangASTContext we used can just implement the FindDecl variant that returns CompilerDecls (and implement the other function by throwing away the ClangASTContext part of the compiler decl).
* [lldb][NFC] Move lock scope where it should beginTatyana Krasnukha2019-12-261-9/+10
|
* [lldb][NFC] Use ClangASTContext in AppleObjCRuntime interfacesRaphael Isemann2019-12-265-61/+46
| | | | | | | This code actually needs a ClangASTContext but instead takes a clang::ASTContext and then retrieves the original ClangASTContext via the global map of ClangASTContexts. Let's change it so that it takes a ClangASTContext which is simpler and faster.
* [lldb] Remove some calls to GetASTContextRaphael Isemann2019-12-262-29/+17
| | | | | | | GetASTContext is really expensive to call as it makes use of the global mapping from ASTContext to ClangASTContext. This replaces all calls where we already have the ClangASTContext around and don't need to call GetASTContext again.
* [lldb][NFC] Use StringRef in ↵Raphael Isemann2019-12-251-2/+2
| | | | ClangASTContext::GetBuiltinTypeForDWARFEncodingAndBitSize
* [lldb] Adapt for NetBSD-9.99.30 ptrace(2) API changesKamil Rytarowski2019-12-242-2/+21
| | | | | | | | Switch from PT_LWPINFO to PT_LWPSTATUS/PT_LWPNEXT. Keep compat support for < 9.99.30. No functional change intended.
* [lldb][NFC] Remove ClangExternalASTSourceCommonRaphael Isemann2019-12-243-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | ClangExternalASTSourceCommon's purpose is to store a map from Decl*/Type* to ClangASTMetadata. Usually this data is accessed via the ClangASTContext interface which then grabs the current ExternalASTSource of its ASTContext, tries to cast it to ClangExternalASTSourceCommon and then accesses the metadata map. If the casting fails the setter does nothing and the getter returns a nullptr as if there was no known metadata for a type/decl. This system breaks as soon as any non-LLDB ExternalASTSource is added via a multiplexer to our existing ExternalASTSource (in which case we suddenly loose all out metadata as the casting always fails with an ExternalASTSource that is not inheriting from ClangExternalASTSourceCommon). This patch moves the metadata map to the ClangASTContext. This gets rid of all the fragile casting, the requirement that every ExternalASTSource in LLDB has to inherit from ClangExternalASTSourceCommon and simplifies the metadata implementation to a simple map lookup. As ClangExternalASTSourceCommon had no other purpose than storing metadata, this patch deletes this class and replaces all uses with clang::ExternalASTSource. No other code changes in this commit beside the AppleObjCDeclVendor which was the only code that did not use the ClangASTContext interface but directly accessed the ClangExternalASTSourceCommon.
* Revert "[lldb] Don't process symlinks deep inside DWARFUnit"Jonas Devlieghere2019-12-232-12/+20
| | | | | This temporarily reverts commit 3cfb6677b2aa20f782d9bb0f7958e61f5a976c16 because it breaks TestCompDirSymLink.py on macOS.
* [lldb] Remove DWARFUnit::AppendDIEsWithTagPavel Labath2019-12-233-24/+6
| | | | | | | This function is not very useful, as it's forcing a materialization of the returned DIEs, and calling it is not substantially simpler than just iterating over the DIEs manually. Delete it, and rewrite the single caller.
* [lldb/DWARF] Fix hostname-stripping logicPavel Labath2019-12-231-0/+2
| | | | | | | | | | | | | | This bit of code is trying to strip everything up to the first colon from all debug info paths, as dwarf2 recommends this syntax for storing the compilation host name. However, this code was too eager, and it ended up stripping the entire compilation directory, if it did not contain a forward slash (or a "x:\"). Normally this does not matter, as all absolute paths will contain one of these patterns, but this does not have to be the case in case the debug info is produced by "clang -fdebug-compilation-dir", which can end up producing a relative compilation directory with no slashes (this is one of the techniques for producing "relocatable" debug info).
* [lldb][NFC] Remove unused 'type' parameter in ↵Raphael Isemann2019-12-232-23/+6
| | | | | | ClangExpressionDeclMap::FindGlobalVariable We never pass something else than a nullptr as the 'type' so the related code in this function is never reached.
OpenPOWER on IntegriCloud