summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb] Remove unused method declarationAlexander Shaposhnikov2017-11-101-4/+0
| | | | | | | | | | FindCompleteObjCDefinitionType is not used anywhere and there is no implementation of it, only a declaration. Test plan: make check-lldb Differential revision: https://reviews.llvm.org/D39884 llvm-svn: 317919
* Support scoped enums in the DWARF AST parserTamas Berghammer2017-11-072-2/+6
| | | | | | | | Subscribers: JDevlieghere Differential Revision: https://reviews.llvm.org/D39545 llvm-svn: 317563
* [lldb] Enable using out-of-tree dwpsAlexander Shaposhnikov2017-10-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously LLDB required the DWP file to be located next to the executable file. This diff uses the helper function Symbols::LocateExecutableSymbolFile to search for DWP files in the standard locations for debug symbols. Test plan: Build a toy test example: main.cpp clang -gsplit-dwarf -g -O0 main.cpp -o main.exe llvm-dwp -e main.exe -o main.exe.dwp mkdir -p debug_symbols mv main.exe.dwp debug_symbols/main.exe.dwp Run lldb: lldb settings set target.debug-file-search-paths ./debug_symbols file ./main.exe br set --name f run Check that debugging works: setting breakpoints, printing local variables. Differential revision: https://reviews.llvm.org/D38568 llvm-svn: 315387
* [DWARFDIE] Rewrite `operator !=` using `operator ==`. NFCI.Davide Italiano2017-10-091-1/+1
| | | | llvm-svn: 315200
* [SymbolFile/DWARF] Simplify two functions. NFCI.Davide Italiano2017-10-091-8/+2
| | | | llvm-svn: 315199
* [lldb] Fix initialization of m_debug_cu_index_mapAlexander Shaposhnikov2017-10-032-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | SymbolFileDWARFDwp contains m_debug_cu_index_map which was previously initialized incorrectly: before m_debug_cu_index.parse is called m_debug_cu_index is empty, thus the map was not actually getting populated properly. This diff moves this step into a private helper method and calls it after m_debug_cu_index.parse inside SymbolFileDWARFDwp::Create. Test plan: Build a toy test example main.cpp clang -gsplit-dwarf -g -O0 main.cpp -o main.exe llvm-dwp -e main.exe -o main.exe.dwp Build LLDB with ENABLE_DEBUG_PRINTF set. Run: lldb -- ./main.exe Check that the indexes are now correct (before this change they were empty) Check that debugging works (setting breakpoints, printing local variables (this was not working before)) Differential revision: http://reviews.llvm.org/D38492 llvm-svn: 314832
* Improve FreeBSD kernel debuggingEd Maste2017-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
* Use ThreadLauncher to launch TaskPool threadsFrancis Ricci2017-09-191-1/+1
| | | | | | | | | | | | | | | | | | Summary: This allows for the stack size to be configured, which isn't possible with std::thread. Prevents overflowing the stack when performing complex operations in the task pool on darwin, where the default pthread stack size is only 512kb. This also moves TaskPool from Utility to Host. Reviewers: labath, tberghammer, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D37930 llvm-svn: 313637
* [lldb] Adjust UpdateExternalModuleListIfNeeded method for the case of *.dwoAlexander Shaposhnikov2017-09-121-1/+23
| | | | | | | | | | | | | | | | | | | | | | | When LLDB loads "external" modules it looks at the presence of DW_AT_GNU_dwo_name. However, when the already created module (corresponding to .dwo itself) is being processed, it will see the presence of DW_AT_GNU_dwo_name (which contains the name of dwo file) and will try to call ModuleList::GetSharedModule again. In some cases (i.e. for empty files) Clang 4.0 generates a *.dwo file which has DW_AT_GNU_dwo_name, but no DW_AT_comp_dir. In this case the method ModuleList::GetSharedModule will fail and the warning will be printed. To workaround this issue, one can notice that in this case we don't actually need to try to load the already loaded module (corresponding to .dwo). Test plan: make check-all Differential revision: https://reviews.llvm.org/D37295 llvm-svn: 313083
* Plugins: fix resolution ambiguity in PDB pluginSaleem Abdulrasool2017-09-091-22/+24
| | | | | | | | | A clang change caused the inclusion of `llvm::Type` and `lldb_private::Type` to be pulled into the global namespace due to the `using namespace llvm;` and `using namespace lldb_private;`. Explicitly qualify the `Type` to resolve the ambiguity. NFC llvm-svn: 312841
* Fix DW_FORM_strp parsingJan Kratochvil2017-09-051-4/+4
| | | | | | Differential revision: https://reviews.llvm.org/D37441 llvm-svn: 312562
* Add support for the DWP debug info formatTamas Berghammer2017-08-257-0/+293
| | | | | | | | | | | | | | | | | | | | Summary: The DWP (DWARF package) format is used to pack multiple dwo files generated by split-dwarf into a single ELF file to make distributing them easier. It is part of the DWARFv5 spec and can be generated by dwp or llvm-dwp from a set of dwo files. Caviats: * Only the new version of the dwp format is supported (v2 in GNU numbering schema and v5 in the DWARF spec). The old version (v1) is already deprecated but binutils 2.24 still generates that one. * Combining DWP files with module debugging is not yet supported. Subscribers: emaste, mgorny, aprantl Differential Revision: https://reviews.llvm.org/D36062 llvm-svn: 311775
* Remove the DWARFExpression -> Clang ExpressionParser dependencyTamas Berghammer2017-08-163-12/+7
| | | | | | | | It was completly unused and broke the part of the encapsulation that common code shouldn't depend on specific plugins or language specific features. llvm-svn: 311000
* Fix LLDB crash accessing unknown DW_FORM_* attributesJan Kratochvil2017-07-315-0/+77
| | | | | | | | | | | | | | | | Current LLDB (that is without DWZ support) crashes accessing Fedora debug info: READ of size 8 at 0x60200000ffc8 thread T0 #0 in DWARFDebugInfoEntry::BuildAddressRangeTable(SymbolFileDWARF*, DWARFCompileUnit const*, DWARFDebugAranges*) const tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:1336 Greg Clayton: We will need a warning to be emitted in SymbolFileDWARF::CalculateAbilities() stating we won't parse the DWARF due to "unsupported DW_FORM value of 0x1f20". Patch has been mostly written by Greg Clayton. Differential revision: https://reviews.llvm.org/D35622 llvm-svn: 309581
* Add support for base address entries in the .debug_ranges sectionTamas Berghammer2017-07-311-18/+19
| | | | | | | | | Summary: Clang recently started to emit base address entries into the .debug_ranges section to reduce the number of relocations needed. Lets make sure LLDB can read them. llvm-svn: 309554
* Improve the fix for PR33875 by not hardcoding the section name.Adrian Prantl2017-07-251-6/+6
| | | | | | This is a follow-up to r308905. llvm-svn: 309019
* Don't allow .debug_types to be parsed as LLDB can crash when enums are not ↵Greg Clayton2017-07-241-0/+15
| | | | | | | | able to be found. Differential Revision: https://reviews.llvm.org/D35734 llvm-svn: 308911
* RFix PR33875 by distinguishing between DWO and clang modules.Adrian Prantl2017-07-241-0/+8
| | | | | | | | This reapplies https://reviews.llvm.org/D35740 with a tweak to find the section by name rather than type. Section types don't distinguish between regular sections and their DWO counterparts. llvm-svn: 308905
* Revert "Fix PR33875 by distinguishing between DWO and clang modules"Adrian Prantl2017-07-231-6/+0
| | | | | | This reverts commit r308850. llvm-svn: 308851
* Fix PR33875 by distinguishing between DWO and clang modulesAdrian Prantl2017-07-231-0/+6
| | | | | | | | | | | | | | The DWO handling code can get confused by clang modules which also use skeleton CUs to point to the object file with the full debug info. This patch detects whether an object is a "real" DWO or a clang module and prevents LLDB from interpreting clang modules as DWO. This fixes the regression in TestWithModuleDebugging. http://llvm.org/bugs/show_bug.cgi?id=33875 Differential Revision: https://reviews.llvm.org/D35740 llvm-svn: 308850
* Move Timer and TraceOptions from Core to UtilityPavel Labath2017-06-297-7/+7
| | | | | | | | | | | | | | Summary: The classes have no dependencies, and they are used both by lldb and lldb-server, so it makes sense for them to live in the lowest layers. Reviewers: zturner, jingham Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34746 llvm-svn: 306682
* Switch TaskMapOverInt to llvm::function_refPavel Labath2017-06-071-3/+2
| | | | | | | | | | The function does not persist the callback, so using a lighter-weight asbtraction seems appropriate. Also tweak the signatures of the lambdas to match what the TaskMap interface expects. llvm-svn: 304924
* Fix assorted compiler warnings. NFCPavel Labath2017-06-061-2/+2
| | | | llvm-svn: 304796
* Remove an expensive lock from TimerPavel Labath2017-05-156-22/+34
| | | | | | | | | | | | | The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
* Rename Error -> Status.Zachary Turner2017-05-123-4/+4
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* [DWARF parser] Produce correct template parameter packsSean Callanan2017-05-113-18/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Templates can end in parameter packs, like this template <class T...> struct MyStruct { /*...*/ }; LLDB does not currently support these parameter packs; it does not emit them into the template argument list at all. This causes problems when you specialize, e.g.: template <> struct MyStruct<int> { /*...*/ }; template <> struct MyStruct<int, int> : MyStruct<int> { /*...*/ }; LLDB generates two template specializations, each with no template arguments, and then when they are imported by the ASTImporter into a parser's AST context we get a single specialization that inherits from itself, causing Clang's record layout mechanism to smash its stack. This patch fixes the problem for classes and adds tests. The tests for functions fail because Clang's ASTImporter can't import them at the moment, so I've xfailed that test. Differential Revision: https://reviews.llvm.org/D33025 llvm-svn: 302833
* Add TaskMap for iterating a function over a set of integersPavel Labath2017-05-051-43/+30
| | | | | | | | | | | | | | | | Summary: Many parallel tasks just want to iterate over all the possible numbers from 0 to N-1. Rather than enqueue N work items, instead just "map" the function across the requested integer space. Reviewers: clayborg, labath, tberghammer, zturner Reviewed By: clayborg, zturner Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D32757 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 302223
* Change UniqueCStringMap to use ConstString as the keyPavel Labath2017-05-023-17/+16
| | | | | | | | | | | | | | | | Summary: UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate. Reviewers: #lldb, clayborg Reviewed By: clayborg Subscribers: labath, jasonmolenda, lldb-commits Differential Revision: https://reviews.llvm.org/D32316 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 301908
* Provide a mechanism to do some pre-loading of symbols up front.Jim Ingham2017-04-282-0/+8
| | | | | | | | | | | Loading a shared library can require a large amount of work; rather than do that serially for each library, this patch will allow parallelization of the symbols and debug info name indexes. From scott.smith@purestorage.com https://reviews.llvm.org/D32598 llvm-svn: 301609
* [DWARF] Fix lookup in the abstract origins of inlined blocks/functionsSean Callanan2017-04-243-2/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLDB uses clang::DeclContexts for lookups, and variables get put into the DeclContext for their abstract origin. (The abstract origin is a DWARF pointer that indicates the unique definition of inlined code.) When the expression parser is looking for variables, it locates the DeclContext for the current context. This needs to be done carefully, though, e.g.: __attribute__ ((always_inline)) void f(int a) { { int b = a * 2; } } void g() { f(3); } Here, if we're stopped in the inlined copy of f, we have to find the DeclContext corresponding to the definition of f – its abstract origin. Clang doesn't allow multiple functions with the same name and arguments to exist. It also means that any variables we see must be placed in the appropriate DeclContext. [Bug 1]: When stopped in an inline block, the function GetDeclContextDIEContainingDIE for that block doesn't properly construct a DeclContext for the abstract origin for inlined subroutines. That means we get duplicated function DeclContexts, but function arguments only get put in the abstract origin's DeclContext, and as a result when we try to look for them in nested contexts they aren't found. [Bug 2]: When stopped in an inline block, the DWARF (for space reasons) doesn't explicitly point to the abstract origin for that block. This means that the function GetClangDeclContextForDIE returns a different DeclContext for each place the block is inlined. However, any variables defined in the block have abstract origins, so they will only get placed in the DeclContext for their abstract origin. In this fix, I've introduced a test covering both of these issues, and fixed them. Bug 1 could be resolved simply by making sure we look up the abstract origin for inlined functions when looking up their DeclContexts on behalf of nested blocks. For Bug 2, I've implemented an algorithm that makes the DeclContext for a block be the containing DeclContext for the closest entity we would find during lookup that has an abstract origin pointer. That means that in the following situation: { // block 1 int a; { // block 2 int b; } } if we looked up the DeclContext for block 2, we'd find the block containing the abstract origin of b, and lookup would proceed correctly because we'd see b and a. However, in the situation { // block 1 int a; { // block 2 } } since there isn't anything to look up in block 2, we can't determine its abstract origin (and there is no such pointer in the DWARF for blocks). However, we can walk up the parent chain and find a, and its abstract origin lives in the abstract origin of block 1. So we simply say that the DeclContext for block 2 is the same as the DeclContext for block 1, which contains a. Lookups will return the same results. Thanks to Jim Ingham for review and suggestions. Differential revision: https://reviews.llvm.org/D32375 llvm-svn: 301263
* Remove lldb streams from the Log class completelyPavel Labath2017-03-151-1/+0
| | | | | | | | | | | | | | | | | | | | | Summary: previously we switched to llvm streams for log output, this completes the switch for the error streams. I also clean up the includes and remove the unused argument from DisableAllLogChannels(). This required adding a bit of boiler plate to convert the output in the command interpreter, but that should go away when we switch command results to use llvm streams as well. Reviewers: zturner, eugene Subscribers: lldb-commits, emaste Differential Revision: https://reviews.llvm.org/D30894 llvm-svn: 297812
* Simplify & correct the patch I wrote in r297441, after thinkingJason Molenda2017-03-101-12/+12
| | | | | | | | about this more I realized I could make the change isolated to whether we decide an empty accelerator table is valid or not. <rdar://problem/30867462> llvm-svn: 297496
* Add a distinction in an apple accelerator table between IsValid andJason Molenda2017-03-101-12/+12
| | | | | | | | | HasContent. If we have a valid accelerator table which has no content, we want to depend on that (empty) table as the authoritative source instead of reading through all the debug info for lookups. <rdar://problem/30867462> llvm-svn: 297441
* Resubmit FileSystem changes.Zachary Turner2017-03-081-1/+5
| | | | | | | | | | This was originall reverted due to some test failures in ModuleCache and TestCompDirSymlink. These issues have all been resolved and the code now passes all tests. Differential Revision: https://reviews.llvm.org/D30698 llvm-svn: 297300
* Revert "Use LLVM for all stat-related functionality."Pavel Labath2017-03-071-5/+1
| | | | | | | | | | | | | | | this reverts r297116 because it breaks the unittests and TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat functionality is not a drop-in replacement for lldb's. The former is based on stat(2) (which does symlink resolution), while the latter is based on lstat(2) (which does not). This also reverts subsequent build fixes (r297128, r297120, 297117) and r297119 (Remove FileSpec dependency on FileSystem) which builds on top of this. llvm-svn: 297139
* Use LLVM for all stat-related functionality.Zachary Turner2017-03-071-1/+5
| | | | | | | | | | This deletes LLDB's FileType enumeration and replaces all users, and all calls to functions that check whether a file exists etc with corresponding calls to LLVM. Differential Revision: https://reviews.llvm.org/D30624 llvm-svn: 297116
* Move many other files from Core -> Utility.Zachary Turner2017-03-063-2/+2
| | | | llvm-svn: 297043
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Isolate Target-specific functionality of DataExtractor.Zachary Turner2017-03-032-5/+5
| | | | | | | | | | | | | | | | In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
* Move Log from Core -> Utility.Zachary Turner2017-03-036-6/+6
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Remove some dead code in FileSpec.Zachary Turner2017-03-034-1/+6
| | | | | | | | This in turn triggered some fallout where other files had been transitively picking up includes that they needed from FileSpec.h, so I've fixed those up as well. llvm-svn: 296855
* Fix various warnings. NFCZachary Turner2017-03-021-2/+2
| | | | llvm-svn: 296717
* Reapply "Refactor log channel registration mechanism"Pavel Labath2017-02-173-221/+34
| | | | | | | | | Changes wrt. previous version: - add #include <atomic>: fix build on windows - add extra {} around the string literals used to initialize llvm::StringLiteral: fix gcc build llvm-svn: 295442
* Revert "Refactor log channel registration mechanism"Pavel Labath2017-02-153-26/+221
| | | | | | | The change breaks on Windows and NetBSD bots. Revert while I investigate. llvm-svn: 295201
* Refactor log channel registration mechanismPavel Labath2017-02-153-221/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have two log channel registration mechanisms. One uses a set of function pointers and the other one is based on the PluginManager. The PluginManager dependency is unfortunate, as logging is also used in lldb-server, and the PluginManager pulls in a lot of classes which are not used in lldb-server. Both approach have the problem that they leave too much to do for the user, and so the individual log channels end up reimplementing command line argument parsing, category listing, etc. Here, I replace the PluginManager-based approach with a one. The new API is more declarative, so the user only needs to specify the list of list of channels, their descriptions, etc., and all the common tasks like enabling/disabling categories are hadled by common code. I migrate the LogChannelDWARF (only user of the PluginManager method) to the new API. In the follow-up commits I'll replace the other channels with something similar. Reviewers: clayborg, zturner, beanz Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D29895 llvm-svn: 295190
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-141-1/+2
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Convert Log class to llvm streamsPavel Labath2017-02-102-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This converts LLDB's logging to use llvm streams instead of lldb_private::Stream and friends. The changes are mostly straight-forward and amount to s/lldb_private::Stream/llvm::raw_ostream. The part worth calling out is the rewrite of the StreamCallback class. Previously this class contained a per-thread buffer of data written. I assume this had something to do with it trying to make sure each log line is delivered as a single event, instead of multiple (possibly interleaved) events. However, this is no longer relevant as the Log class already writes things to a temporary buffer and then delivers the message as a single "write", so I have just removed the code in question. Reviewers: zturner, clayborg Subscribers: emaste, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D29615 llvm-svn: 294736
* Remove the verbose category in the dwarf channelPavel Labath2017-02-063-9/+3
| | | | llvm-svn: 294219
* Switch std::call_once to llvm::call_onceKamil Rytarowski2017-02-062-3/+6
| | | | | | | | | | | | | | | | | | | | | Summary: The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms. This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger. Sponsored by <The NetBSD Foundation> Reviewers: labath, joerg, emaste, mehdi_amini, clayborg Reviewed By: labath, clayborg Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D29288 llvm-svn: 294202
* Move classes from Core -> Utility.Zachary Turner2017-02-0223-29/+29
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
OpenPOWER on IntegriCloud