summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins
Commit message (Collapse)AuthorAgeFilesLines
...
* ProcessElfCore: Remove linux and freebsd NT_*** constantsPavel Labath2019-08-072-46/+21
| | | | | | | These are already defined in llvm/BinaryFormat/ELF.h. Leaving the NetBSD and OpenBSD constants as-is, as they have no llvm counterparts. llvm-svn: 368168
* ObjectFileELF: Remove NT_*** constantsPavel Labath2019-08-071-36/+1
| | | | | | | llvm now has definitions of those in BinaryFormat/ELF.h. Use those instead. llvm-svn: 368159
* Detect HAVE_SYS_TYPES_H in lldbHaibo Huang2019-08-072-0/+4
| | | | | | | | | | | | | | | | Summary: After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in Platform.h, or anywhere else in lldb. This change fixes that. Reviewers: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65822 llvm-svn: 368125
* [lldb][NFC] Minor refactorings to (Clang)ExpressionSourceCodeRaphael Isemann2019-08-061-6/+6
| | | | llvm-svn: 368082
* [SymbolFile] Remove commented out methodAlex Langford2019-08-062-204/+0
| | | | llvm-svn: 368075
* Update LLDB to follow changes in llvm::DWARFDebugNames::NameIndex (4/5)Igor Kudrin2019-08-061-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D65640 llvm-svn: 368033
* ObjectFileELF: permit thread-local sections with overlapping file addressesPavel Labath2019-08-061-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In an attempt to make file-address-based lookups more predictable, in D55998 we started ignoring sections which would result in file address overlaps. It turns out this was too aggressive because thread-local sections typically will have file addresses which apear to overlap regular data/code. This does not cause a problem at runtime because thread-local sections are loaded into memory using special logic, but it can cause problems for lldb when trying to lookup objects by their file address. This patch changes ObjectFileELF to permit thread-local sections to overlap regular ones by essentially giving them a separate address space. It also makes them more symmetrical to regular sections by creating container sections from PT_TLS segments. Simultaneously, the patch changes the regular file address lookup logic to ignore sections with the thread-specific bit set. I believe this is what the users looking up file addresses would typically expect, as looking up thread-local data generally requires more complex logic (e.g. DWARF has a special opcode for that). Reviewers: clayborg, jingham, MaskRay Subscribers: emaste, aprantl, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D65282 llvm-svn: 368010
* SymbolVendor: Remove passthrough methodsPavel Labath2019-08-064-29/+24
| | | | | | | | | | After the recent refactorings the SymbolVendor passthrough no longer serve any purpose. This patch removes those methods, and updates all callsites to go to the symbol file directly -- in most cases that just means calling GetSymbolFile()->foo() instead of GetSymbolVendor()->foo(). llvm-svn: 368001
* SymbolVendorELF: Perform build-id lookup even without a debug linkPavel Labath2019-08-061-4/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: The debug link and build-id lookups are two independent ways one can search for a separate symbol file. However, our implementation in SymbolVendorELF was tying the two together and refusing to look up the symbol file based on a build id if the file did not contain a debug link. This patch makes it possible to search for the symbol file with just one of the two methods available. To demonstrate, I split the build-id-case test into two, so that we test the search using both methods. Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap Subscribers: emaste, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65561 llvm-svn: 367994
* [lldb][NFC] Remove unnecessary cast in ClangUserExpressionRaphael Isemann2019-08-061-5/+3
| | | | llvm-svn: 367989
* [Gardening] Remove dead code from ASTDumper (NFC)Jonas Devlieghere2019-08-061-4/+0
| | | | | | These functions are not referenced. llvm-svn: 367978
* [Gardening] Remove dead code from ScriptInterpreterPython (NFC)Jonas Devlieghere2019-08-062-24/+3
| | | | | | The terminal state is never saved or restored. llvm-svn: 367977
* [lldb][NFC] Document and refactor ↵Raphael Isemann2019-08-051-4/+16
| | | | | | ClangPersistentVariables::RemovePersistentVariable llvm-svn: 367936
* [lldb][NFC] Refactor ClangUserExpression::UpdateLanguageForExprRaphael Isemann2019-08-052-16/+21
| | | | | | | | | The UpdateLanguageForExpr should only update the language, but over time it started to do also do different things related to the generation of the expression source code. This patch refactors all the source code generation part into its own function. llvm-svn: 367922
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367867
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | | | debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. llvm-svn: 367861
* [lldb][NFC] Fix documentation for ↵Raphael Isemann2019-08-052-4/+3
| | | | | | ClangPersistentVariables::m_next_persistent_variable_id llvm-svn: 367857
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+2
| | | | | | assembly format for better readability llvm-svn: 367850
* [lldb][NFC] Clang format GetNextPersistentVariableName signatureRaphael Isemann2019-08-051-1/+1
| | | | llvm-svn: 367843
* [lldb] Move redundant persistent variable counter to ClangPersistentVariablesRaphael Isemann2019-08-051-2/+12
| | | | | | | | | | | | | | | | | Currently Target::m_next_persistent_variable_index is counting up for our persistent variables ($0, $1, ...) but we also have a unused counter that is supposed to do this in ClangPersistentVariables but that stays always at 0 (because we currently increase the target counter when we should increase that unused counter). This patch removes the counter in Target and lets the documented counter in ClangPersistentVariables do the variable counting. Patch *should* be NFC, but it might unexpectedly bring LLDB to new code paths that could contain exciting new bugs to fix. llvm-svn: 367842
* [lldb][NFC] Remove unimplemented ClangExpressionSourceCode::GetNumBodyLinesRaphael Isemann2019-08-051-2/+0
| | | | llvm-svn: 367830
* ObjectFile[ELF]: Refactor gnu_debuglink interfacePavel Labath2019-08-054-81/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The contents of the gnu_debuglink section were passed through the GetDebugSymbolFilePaths interface, which was more generic than needed. As the only class implementing this function is ObjectFileELF, we can modify the function to return just a single FileSpec (instead of a list). Also, since the SymbolVendorELF already assumes ELF object files, we don't have to make this method available on the generic ObjectFile interface -- instead we can put it on ObjectFileELF directly. This change also makes is so that if the Module has an explicit symbol file spec set, we disregard the value the value of the debug link (instead of doing a secondary lookup using that). I think it makes sense to honor the users wishes if he had explicitly set the symbol file spec, and this seems to be consistent with what SymbolVendorMacOSX is doing (SymbolVendorMacOSX.cpp:125). The main reason for making these changes is to make the treatment of build-ids and debug links simpler in the follow-up patch. Reviewers: clayborg, jankratochvil, mgorny, espindola Subscribers: emaste, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65560 llvm-svn: 367824
* Remove SymbolVendor::GetSymtabPavel Labath2019-08-051-15/+11
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes the GetSymtab method from the SymbolVendor, which is a no-op as it's implementation just forwards to the relevant SymbolFile. Instead it creates a Module::GetSymtab, which calls the SymbolFile method directly. All callers have been updated to use the Module method directly instead of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced intentation in a lot of deeply nested code. Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65569 llvm-svn: 367820
* Remove usage of usleep in generic codePavel Labath2019-08-052-6/+7
| | | | | | | | This function is not portable, and there are only a handful of usages of it anyway. Replacing it with std::this_thread::sleep_for enables us to get rid of the compatibility code in PosixApi.h. llvm-svn: 367814
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-052-4/+4
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Fix ClangASTContext::CreateParameterDeclaration to not call addDeclShafik Yaghmour2019-08-022-2/+2
| | | | | | | | | Summary: The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang. Differential Revision: https://reviews.llvm.org/D65414 llvm-svn: 367726
* [Formatters] Temporarily disable libc++ std::function formatter due to ↵Shafik Yaghmour2019-08-021-6/+0
| | | | | | | | | | performance issue Summary: We have been seeing increased reports of performance issue around large project and formatting std::function variables especially in functions signatures in back traces. There are some possible fixes but exploring those fixes may take time and it is better to temporarily disable the formatter due to its impact and re-enable it once we have a fix. Differential Revision: https://reviews.llvm.org/D65666 llvm-svn: 367701
* Fix PC adjustment in StackFrame::GetSymbolContextJoseph Tremoulet2019-08-028-55/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update StackFrame::GetSymbolContext to mirror the logic in RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the pc decrement when the given frame is a signal trap handler frame or the parent of one, because the pc may not follow a call in these frames. Accomplish this by adding a behaves_like_zeroth_frame field to lldb_private::StackFrame, set to true for the zeroth frame, for signal handler frames, and for parents of signal handler frames. Also add logic to propagate the signal handler flag from UnwindPlan to the FrameType on the RegisterContextLLDB it generates, and factor out a helper to resolve symbol and address range for an Address now that we need to invoke it in four places. Reviewers: jasonmolenda, clayborg, jfb Reviewed By: jasonmolenda Subscribers: labath, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64993 llvm-svn: 367691
* SymbolVendor: Introduce Module::GetSymbolFilePavel Labath2019-08-022-105/+97
| | | | | | | | | | | | | | | | | | | | | Summary: This is the next step in avoiding funneling all SymbolFile calls through the SymbolVendor. Right now, it is just a convenience function, but it allows us to update all calls to SymbolVendor functions to access the SymbolFile directly. Once all call sites have been updated, we can remove the GetSymbolVendor member function. This patch just updates the calls to GetSymbolVendor, which were calling it just so they could fetch the underlying symbol file. Other calls will be done in follow-ups. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65435 llvm-svn: 367664
* Format OptionEnumValueElement (NFC)Jonas Devlieghere2019-08-022-17/+43
| | | | | | | | | | Reformat OptionEnumValueElement to make it easier to distinguish between its fields. This also removes the need to disable clang-format for these arrays. Differential revision: https://reviews.llvm.org/D65489 llvm-svn: 367638
* [clang] Change FileManager to use llvm::ErrorOr instead of null on failureHarlan Haskins2019-08-012-6/+9
| | | | | | | | | | | | | | | | | | Summary: Currently, clang's FileManager uses NULL as an indicator that a particular file did not exist, but would not propagate errors like permission issues. Instead, teach FileManager to use llvm::ErrorOr internally and return rich errors for failures. Reviewers: arphaman, bruno, martong, shafik Subscribers: nemanjai, kbarton, MaskRay, jkorous, dexonsmith, kadircet, jsji, cfe-commits, lldb-commits Tags: #clang, #lldb Differential Revision: https://reviews.llvm.org/D65534 llvm-svn: 367618
* [lldb][NFC] Make ClangDiagnostic::m_fixit_vec privateRaphael Isemann2019-08-011-0/+1
| | | | llvm-svn: 367542
* [GDBRemote] Reflow comments and improve docs.Jonas Devlieghere2019-07-311-31/+35
| | | | | | | | Improved the GDB client base documentation while I was reading through it. Looks like it got messed up during the automatic comment reflow a while ago. llvm-svn: 367481
* Don't crash when pass by value struct has no definition.Greg Clayton2019-07-311-1/+1
| | | | llvm-svn: 367441
* [ProcessWindows] Choose a register context file by preprocessorTatyana Krasnukha2019-07-315-10/+19
| | | | | | | | | | Replaced Cmake option based check with the preprocessor macro as CMAKE_SYSTEM_PROCESSOR doesn't work as expected on Windows. Fixes llvm.org/pr42724 Differential Revision: https://reviews.llvm.org/D65409 llvm-svn: 367414
* Add llvm-style RTTI to ObjectFile hierarchyPavel Labath2019-07-3118-35/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On the heels of D62934, this patch uses the same approach to introduce llvm RTTI support to the ObjectFile hierarchy. It also replaces the existing uses of GetPluginName doing run-time type checks with llvm::dyn_cast and friends. This formally introduces new dependencies from some other plugins to ObjectFile plugins. However, I believe this is fine because: - these dependencies were already kind of there, and the only reason we could get away with not modeling them explicitly was because the code was relying on magically knowing what will GetPluginName() return for a particular kind of object files. - the dependencies themselves are logical (it makes sense for SymbolVendorELF to depend on ObjectFileELF), or at least don't actively get in the way (the JitLoaderGDB->MachO thing). - they don't introduce any new dependency loops as ObjectFile plugins don't depend on any other plugins Reviewers: xiaobai, JDevlieghere, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65450 llvm-svn: 367413
* SymbolVendor: Remove the object file member variablePavel Labath2019-07-3114-117/+123
| | | | | | | | | | | | | | | | | | Summary: The last responsibility of the SymbolVendor was to hold an owning reference to the object file (in case symbols are being read from a different file than the main module). As SymbolFile classes already hold a non-owning reference to the object file, we can easily remove this responsibility of the SymbolVendor by making the SymbolFile reference owning. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65401 llvm-svn: 367392
* Change '|' to '&' in conditional.Richard Trieu2019-07-311-1/+1
| | | | | | | | Bitwise-or with a non-zero constant will always evaluate to true. Switch to bitwise-and which will only evalute to true if the specified bit is set in the other operand. llvm-svn: 367386
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-3019-125/+263
| | | | | | | | | | | | | | | | | | Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
* [SymbolFile] SymbolFileDWARF::ParseLineTable should lock its moduleAlex Langford2019-07-301-1/+1
| | | | | | | | | As of svn rL367298, SymbolFileDWARF locks the module in many cases where it needs to parse some aspect of the DWARF symbol file. SymbolFileDWARF::ParseLineTable needs to lock the module because SymbolVendor::ParseLineTable no longer locks it. llvm-svn: 367358
* PECOFF: Fix a "memset clearing an object of non-trivial type" warningPavel Labath2019-07-302-34/+32
| | | | | | | | | | | | This time, the warning pointed to an actual problem, because the coff_opt_header structure contained a std::vector. I guess this happened to work because the all-zero state was a valid representation of an empty vector, but its not a good idea to rely on that. I remove the memset, and have the structure clear its members in the constructor instead. llvm-svn: 367299
* SymbolVendor: Move locking into the Symbol FilesPavel Labath2019-07-306-16/+74
| | | | | | | | | | | | | | | | | | | | | | Summary: The last bit of functionality in SymbolVendor passthrough functions is the locking the module mutex. While it may be nice doing the locking in a central place, we weren't really succesful in doing that right now, because some SymbolFile function could still be called without going through the SymbolVendor. This meant in SymbolFileDWARF (the only battle-tested symbol file implementation) roughly a half of the functions was taking additional locks and another half was asserting that the lock is already held. By making the SymbolFile responsible for locking, we can at least make the situation in SymbolFileDWARF more consistent. Reviewers: clayborg, JDevlieghere, jingham, jdoerfert Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D65329 llvm-svn: 367298
* [NFC] avoid AlignedCharArray in lldbJF Bastien2019-07-292-3/+3
| | | | | | As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio. llvm-svn: 367275
* [Reproducers] Pass FileCollector around as a shared_ptr (NFC)Jonas Devlieghere2019-07-291-3/+5
| | | | | | | | | | | Instead of passing the FileCollector around as a reference or raw pointer, use a shared_ptr. This change's motivation is twofold. First it adds compatibility for the newly added `FileCollectorFileSystem`. Secondly, it addresses a lifetime issue we only see when LLDB is used from Xcode, where a reference to the FileCollector outlives the reproducer instance. llvm-svn: 367258
* [lldb] Qualify includes of Properties[Enum].inc files. NFCJordan Rupprecht2019-07-2921-42/+42
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a bit more explicit, and makes it possible to build LLDB without varying the -I lines per-directory. (The latter is useful because many build systems only allow this to be configured per-library, and LLDB is insufficiently layered to be split into multiple libraries on stricter build systems). (My comment on D65185 has some more context) Reviewers: JDevlieghere, labath, chandlerc, jdoerfert Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65397 Patch by Sam McCall! llvm-svn: 367241
* [lldb] Also include the array definition in Properties.incJonas Devlieghere2019-07-297-39/+28
| | | | | | | | | | | | | | | | Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
* DWARF: Improve type safety or range lists parsingPavel Labath2019-07-265-16/+10
| | | | | | | | | Delete the abstract GetOffset function, which is only defined for rnglists entries. Instead fix up entries which refer to the range list classes so that one can statically know that he is dealing with the rnglists section and call the function that way. llvm-svn: 367106
* Fix some "control reaches end of non-void function" warningsPavel Labath2019-07-261-0/+2
| | | | llvm-svn: 367095
* ObjectFileELF: Use llvm::JamCRC to refactor CRC32 computationFangrui Song2019-07-261-67/+9
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D65318 llvm-svn: 367090
* Let tablegen generate property definitionsJonas Devlieghere2019-07-2521-91/+216
| | | | | | | | | | | | | | | | | | | | | | | | | | Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
OpenPOWER on IntegriCloud