summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile
Commit message (Collapse)AuthorAgeFilesLines
...
* DWARF: Introduce DWARFTypeUnit classPavel Labath2019-05-2210-47/+111
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces the DWARFTypeUnit class, and teaches lldb to parse type units out of both the debug_types section (DWARF v4), and from the regular debug_info section (DWARF v5). The most important piece of functionality - resolving DW_AT_signatures to connect type forward declarations to their definitions - is not implemented here, but even without that, a lot of functionality becomes available. I've added tests for the commands that start to work after this patch. The changes in this patch were greatly inspired by D61505, which in turn took over changes from D32167. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mgorny, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D62008 llvm-svn: 361360
* Remove `SymbolFileDWARF *` when there is already `DWARFUnit *`Jan Kratochvil2019-05-218-249/+186
| | | | | | | | | | | | | | In D61502#1503247 @clayborg suggested that SymbolFileDWARF *dwarf2Data is really redundant in all the calls with also having DWARFUnit *cu. So remove it. One `SymbolFileDWARF *` nullptr check (DWARFDebugInfoEntry::GetDIENamesAndRanges) could be removed, other two nullptr checks (DWARFDebugInfoEntry::GetName and DWARFDebugInfoEntry::AppendTypeName) need to stay in place (now for `DWARFUnit *`). Differential Revision: https://reviews.llvm.org/D62011 llvm-svn: 361277
* DWARF: Port debug_addr over to DWARFContextPavel Labath2019-05-218-24/+13
| | | | llvm-svn: 361232
* DWARF: Introduce DWARFUnitHeader classPavel Labath2019-05-215-147/+168
| | | | | | | | | | | | | | | | | | | Summary: This patch introduces the DWARFUnitHeader class. Its purpose (and its structure, to the extent it was possible to make it) is the same as its LLVM counterpart -- to extract the unit header information before we actually construct the unit, so that we know which kind of units to construct. This is needed because as of DWARF5, type units live in the .debug_info section, which means it's not possible to statically determine the type of units in a given section. Reviewers: aprantl, clayborg, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62073 llvm-svn: 361224
* DWARF: Port most of other sections over to DWARFContextPavel Labath2019-05-209-126/+80
| | | | | | | | This moves the sections from SymbolFileDWARF to DWARFContext, where it was trivial to do so. A couple of sections are still left in SymbolFileDWARF. These will be handled by separate patches. llvm-svn: 361127
* Make DWARFContext dwo-aware and port debug_info sections overPavel Labath2019-05-179-34/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The previous attempt and moving section handling over to DWARFContext (D59611) failed because it did not take into account the dwo sections correctly. All DWARFContexts (even those in SymbolFileDWARFDwo) used the main module for loading the sections, but in the dwo scenario some sections should come from the dwo file. This patch fixes that by making the DWARFContext aware of whether it a dwo context or a regular one. A dwo context gets two sections lists, and it knows where to look for a particular type of a section. This isn't fully consistent with how the llvm DWARFContext behaves, because that one leaves it up to the user to know whether it should ask for a dwo section or not. However, for the time being, it seems useful to have a single entity which knows how to peice together the debug info in dwo and non-dwo scenarios. The rough roadmap for the future is: - port over the rest of the sections to DWARFContext - find a way to get rid of SymbolFileDWARFDwo/Dwp/DwpDwo. This will likely involve adding the ability for the DWARFContext to spawn dwo sub-contexts, similarly to how it's done in llvm. - get rid of the special handling of the "dwo" contexts by making sure everything knows whether it should ask for the .dwo version of the section or not (similarly to how llvm's DWARFUnits do that) To demonstrate how the DWARFContext should behave in this new world, I port the debug_info section (which is debug_info.dwo in the dwo file) handling to DWARFContext. The rest of the sections will come in subsequent patches. Reviewers: aprantl, clayborg, JDevlieghere Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D62012 llvm-svn: 361000
* DWARFContext: Return empty data extractors instead of null pointersPavel Labath2019-05-164-27/+23
| | | | | | | | | | | | | | | | | | | | | | | Summary: There are several reasons for doing this: - generally, there's no reason to differentiate between a section being absent and it being present, but empty - it matches more closely what llvm DWARF parser is doing (which also doesn't differentiate the two cases) - SymbolFileDWARF also doesn't differentiate the two cases, which makes porting the rest of sections easier - it fixes a bug in how the return-null-if-empty logic was implemented (it returned nullptr only the second time we tried to get the debug_aranges section), which meant that we hit an assert when trying to parse an empty-but-present section Reviewers: JDevlieghere, clayborg, aprantl Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D61942 llvm-svn: 360874
* DWARF: Add ability to reference debug info coming from multiple sectionsPavel Labath2019-05-1616-55/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to precisely address debug info in situations when a single file can have more than one debug-info-bearing sections (as is the case with type units in DWARF v4). The changes here can be classified into roughly three categories: - the code which addresses a debug info by offset gets an additional argument, which specifies the section one should look into. - the DIERef class also gets an additional member variable specifying the section. This way, code dealing with DIERefs can know which section is the object referring to. - the user_id_t encoding steals one bit from the dwarf_id field to store the section. This means the total number of separate object files (apple .o, or normal .dwo) is limited to 2 billion, but that is fine as it's not possible to hit that number without switching to DWARF64 anyway. This patch is functionally equivalent to (and inspired by) the two patches (D61503 and D61504) by Jan Kratochvil, but there are differences in the implementation: - it uses an enum instead of a bool flag to differentiate the sections - it increases the size of DIERef struct instead of reducing the amount of addressable debug info - it sets up DWARFDebugInfo to store the units in a single vector instead of two. This sets us up for the future in which type units can also live in the debug_info section, and I believe it's cleaner because there's no need for unit index remapping There are no tests with this patch as this is essentially NFC until we start parsing type units from the debug_types section. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: arphaman, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61908 llvm-svn: 360872
* Permit cross-CU referencesJan Kratochvil2019-05-1513-131/+110
| | | | | | | | | | | | | | So far dw_offset_t was global for the whole SymbolFileDWARF but with .debug_types the same dw_offset_t may mean two different things depending on its section (=CU). So references now return whole new referenced DWARFDIE instead of just dw_offset_t. This means that some functions have to now handle 16 bytes instead of 8 bytes but I do not see that anywhere performance critical. Differential Revision: https://reviews.llvm.org/D61502 llvm-svn: 360795
* DWARF: s/CompileUnit/Unit/ in DWARFFormValuePavel Labath2019-05-155-59/+51
| | | | | | | | The class has been converted to use DWARFUnit, but a number of uses of the words compile unit remained. This removes all such references Get/SetCompileUnit becomes Get/SetUnit, and m_cu becomes m_unit. llvm-svn: 360754
* DWARF/NFC: Centralize DIERef conversionsPavel Labath2019-05-143-40/+24
| | | | | | | | | | | | | apple and manual indexing code were creating a DIERef in a bunch of places. Though the code itself is not much, it is also easy to simplify by factoring out the DIERef creation. In HashedNameToDIE I create a conversion operator from DIEInfo to DIERef, and in ManualDWARFIndex I just create the DIERef in a global variable up-front. This also reduces the diff in follow-up patches which change how DIERefs are constructed. llvm-svn: 360669
* DWARF/DIERef: remove non-const operator<Pavel Labath2019-05-131-2/+0
| | | | | | It serves no purpose as one can always invoke the const version instead. llvm-svn: 360583
* Breakpad: Generate unwind plans from STACK CFI recordsPavel Labath2019-05-132-2/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the GetUnwindPlan interface (added in the previous patch) for SymbolFileBreakpad, and uses it to generate unwind plans from STACK CFI records in breakpad files. We first perform a light-weight parse of the breakpad in order to build up a map of regions covered by the unwind info so that we can later jump to the right record when we need to unwind a specific function. The actual parsing is relatively straight-forward, as the STACK CFI records are just another (text) form of the eh_frame unwind instructions, and the same goes for lldb's UnwindPlans. The newly-introduced PostfixExpression API is used to convert the breakpad postfix expressions into DWARF. The generated dwarf expressions are stored in a BumpPtrAllocator, as the UnwindPlan does not take ownership of the expression data it references (usually this is static data in an object file, so special ownership is needed). At this moment the generated unwind plans aren't used in the actual unwind machinery (only in the image show-unwind command), but that is coming in a separate patch. Reviewers: amccarth, clayborg, markmentovai Subscribers: aprantl, jasonmolenda, lldb-commits Differential Revision: https://reviews.llvm.org/D61733 llvm-svn: 360574
* [NativePDB] Support member function types in PdbAstBuilderAleksandr Urakov2019-05-132-0/+19
| | | | | | | | | | | | | | | | | Summary: This patch implements missing case in PdbAstBuilder::CreateType for LF_MFUNCTION. This is necessary, for example, in stack unwinding of struct methods. Reviewers: amccarth, aleksandr.urakov Reviewed By: amccarth Subscribers: abidh, teemperor, lldb-commits, leonid.mashinskiy Differential Revision: https://reviews.llvm.org/D61128 llvm-svn: 360569
* [DWARF] Use sequential integers for the IDs of the SymbolFileDWOsPavel Labath2019-05-132-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of using the offset of the contained compile unit, we use it's ID. The goal of this change is two-fold: - free up space in the user_id_t representation to enable storing the debug-info-carrying section (debug_types/debug_info) without decreasing the amount of debug info we can address (as would be the case with D61503). - be a step towards supporting DWO files containing more than one unit (important for debug_types+dwo, but can also happen with regular dwo+lto). For this part to fully work we'd still need to add a way to lookup the SymbolFileDWO without going through GetCompileUnitAtIndex, but making sure things don't accidentally work because the SymbolFile ID is the same as compile unit offset is a step towards that. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mehdi_amini, dexonsmith, tberghammer, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61783 llvm-svn: 360565
* Fix file names in file headers. NFCFangrui Song2019-05-134-4/+4
| | | | llvm-svn: 360554
* Finish renaming CompileUnit -> UnitJan Kratochvil2019-05-1012-93/+85
| | | | | | | | | | | | | D42892 changed a lot of code to use superclass DWARFUnit instead of its subclass DWARFCompileUnit. Finish this change more thoroughly for any *CompileUnit* -> *Unit* names. Later patch will introduce DWARFTypeUnit which needs to be sometimes different from DWARFCompileUnit and it would be confusing without this renaming. Differential Revision: https://reviews.llvm.org/D61501 llvm-svn: 360443
* [DWARF] Centralize user_id <-> DWARFDIE conversionsPavel Labath2019-05-086-114/+55
| | | | | | | | | | | | | | | | | | | | | | | Summary: The logic for translating a user_id into a DWARFDIE was replicated in several places. This removes that redundancy and settles on a single implementation in SymbolFileDWARF. The reason for choosing that instead of DIERef was that we were always immediately converting the returned DIERef into a DWARFDIE anyway, which meant that one had to specify the SymbolFileDWARF argument twice (once to get the DIERef, and once to get the actual DIE). Also, passing a higher-level object (SymbolFileDWARF) into a lower-level one (DIERef) seemed like a less intuitive arrangement than doing things the other way around. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: tberghammer, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61648 llvm-svn: 360246
* Merge GetCompileUnitAtOffset + GetCompileUnitContainingDIEOffsetJan Kratochvil2019-05-062-49/+27
| | | | | | | | | | | | | | | | These two methods are very similar and various refactorizations need to modify both similar ways. One could also just remove GetCompileUnitAtOffset and make GetCompileUnitContainingDIEOffset to also accept offset of the CU itself (currently it accepts only DIE offsets after the CU header). But that would be less safe regarding some internal sanity checking. Further code refactorization has been suggested by Pavel Labath. Differential Revision: https://reviews.llvm.org/D61498 llvm-svn: 360038
* [DWARF] Reimplement/simplify DWARFUnit::GetIDPavel Labath2019-05-068-41/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The implementation of GetID used a relatively complicated algorithm, which returned some kind of an offset of the unit in some file (depending on the debug info flavour). The only thing this ID was used for was to enable subseqent retrieval of the unit from the SymbolFile. This can be made simpler if we just make the "ID" of the unit an index into the list of the units belonging to the symbol file. We already support indexed access to the units, so each unit already has a well "index" -- this just makes it accessible from within the unit. To make the distincion between "id" and "offset" clearer (and help catch any misuses), I also rename DWARFDebugInfo::GetCompileUnit (which accesses by offset) into DWARFDebugInfo::GetCompileUnitAtOffset. On its own, this only brings a minor simplification, but it enables further simplifications in the DIERef class (coming in a follow-up patch). Reviewers: JDevlieghere, clayborg, aprantl Subscribers: arphaman, jdoerfert, lldb-commits, tberghammer, jankratochvil Differential Revision: https://reviews.llvm.org/D61481 llvm-svn: 360014
* Remove unnecessary check in SymbolFileDWARF::ParseImportedModulesRaphael Isemann2019-05-021-3/+0
| | | | | | | | | | | | | | | | | | Summary: This check seems unnecessary as we already assert the same condition above and also access `sc.comp_unit` before this check. Reviewers: aprantl Reviewed By: aprantl Subscribers: jdoerfert, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61394 llvm-svn: 359813
* Set a CXXRecordDecl to not be passed in registers if DW_CC_pass_by_reference ↵Shafik Yaghmour2019-05-011-0/+8
| | | | | | | | | | | | | when loading from DWARF Summary: This will fix a bug where during expression parsing we are not setting a CXXRecordDecl to not be passed in registers and the resulting code generation is wrong. The DWARF attribute DW_CC_pass_by_reference tells us that we should not be passing in registers i.e. RAA_Indirect. This change depends this clang change which fixes the fact that the ASTImporter does not copy RecordDeclBits for CXXRecordDecl: https://reviews.llvm.org/D61140 Differential Revision: https://reviews.llvm.org/D61146 llvm-svn: 359732
* Removed unnecessary conversion to StringRefRaphael Isemann2019-05-011-3/+1
| | | | llvm-svn: 359664
* PostfixExpression: move DWARF generator out of NativePDB internalsPavel Labath2019-04-261-183/+16
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new dwarf generator is pretty much a verbatim copy of the one in PDB. In order to write a pdb-independent test for it, I needed to write a dummy "symbol resolver", which (together with the fact that I'll need one more for breakpad-specific resolution logic) prompted me to create a more simple interface for algorithms which replace or "resolve" SymbolNodes. The resolving algorithms in NativePDB have been updated to make use of that too. I have removed a couple of NativePDB tests which weren't testing anything pdb-specific and where the tested functionality was covered by the new format-agnostic tests I have added. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D61056 llvm-svn: 359288
* Fix infinite recursion when calling C++ template functionsFrederic Riss2019-04-241-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we encounter a templated function in the debug information, we were creating an AST that looked like this: FunctionTemplateDecl 0x12980ab90 <<invalid sloc>> <invalid sloc> foo<int> |-TemplateTypeParmDecl 0x12980aad0 <<invalid sloc>> <invalid sloc> class depth 0 index 0 T |-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern | |-TemplateArgument type 'int' | `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int' `-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern |-TemplateArgument type 'int' `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int' Note that the FunctionTemplateDecl has 2 children which are identical (as in have the same address). This is not what Clang is doing: FunctionTemplateDecl 0x7f89d206c6f8 </tmp/template.cpp:1:1, line:4:1> line:2:5 foo |-TemplateTypeParmDecl 0x7f89d206c4a8 <line:1:10, col:19> col:19 referenced typename depth 0 index 0 T |-FunctionDecl 0x7f89d206c660 <line:2:1, line:4:1> line:2:5 foo 'int (T)' | `-ParmVarDecl 0x7f89d206c570 <col:9, col:11> col:11 t1 'T' `-FunctionDecl 0x7f89d206cb60 <line:2:1, line:4:1> line:2:5 used foo 'int (int)' |-TemplateArgument type 'int' `-ParmVarDecl 0x7f89d206ca68 <col:9, col:11> col:11 t1 'int':'int' The 2 chidlren are different and actually repesent different things: the first one is the unspecialized version and the second one is specialized. (Just looking at the names shows another major difference which is that we create the parent with a name of "foo<int>" when it should be just "foo".) The fact that we have those 2 identical children confuses the ClangImporter and generates an infinite recursion (reported in https://llvm.org/pr41473). We cannot create the unspecialized version as the debug information doesn't contain a mapping from the template parameters to their use in the prototype. This patch just creates 2 different FunctionDecls for those 2 children of the FunctionTemplateDecl. This avoids the infinite recursion and allows us to call functions. As the XFAILs in the added test show, we've still got issues in our handling of templates. I believe they are mostly centered on the fact that we create do not register "foo" as a template, but "foo<int>". This is a bigger change that will need changes to the debug information generation. I believe this change makes sense on its own. Reviewers: shafik, clayborg, jingham Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D61044 llvm-svn: 359140
* PostfixExpression: move parser out of NativePDB internalsPavel Labath2019-04-241-96/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The postfix expressions in PDB and breakpad symbol files are similar enough that they can be parsed by the same parser. This patch generalizes the parser in the NativePDB plugin and moves it into the PostfixExpression file created in the previous commit (r358976). The generalization consists of treating any unrecognised token as a "symbol" node (previously these would only be created for tokens starting with "$", and other token would abort the parse). This is needed because breakpad symbols can also contain ".cfa" tokens, which refer to the frame's CFA. The cosmetic changes include: - using a factory function instead of a class for creating nodes (this is more generic as it allows the same BumpPtrAllocator to be used for other things too) - using dedicated function for parsing operator tokens instead of a DenseMap (more efficient as we don't need to create the DenseMap every time). Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny Differential Revision: https://reviews.llvm.org/D61003 llvm-svn: 359073
* Lock accesses to OptionValueFileSpecList objectsFrederic Riss2019-04-232-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Before a Debugger gets a Target, target settings are routed to a global set of settings. Even without this, some part of the LLDB which exist independently of the Debugger object (the Module cache, the Symbol vendors, ...) access directly the global default store for those settings. Of course, if you modify one of those global settings while they are being read, bad things happen. We see this quite a bit with FileSpecList settings. In particular, we see many cases where one debug session changes target.exec-search-paths while another session starts up and it crashes when one of those accesses invalid FileSpecs. This patch addresses the specific FileSpecList issue by adding locking to OptionValueFileSpecList and never returning by reference. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60468 llvm-svn: 359028
* Move postfix expression code out of the NativePDB pluginPavel Labath2019-04-231-233/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The NativePDB plugin contains code to convert "programs" describing the layout of function frames into dwarf (for easier interaction with the rest of lldb). This functionality is useful for the Breakpad plugin too, as it contains the same kind of expressions (because breakpad info is generated from pdb files). In this patch, I move the core classes of this code into a common place, where it can be used from both files. Previously, these were the details of the implementation, but here I am exposing them (instead of just a single "string->string" conversion function), as breakpad will need to use these in a slightly different way. The reason for that is that breakpad files generated from dwarf expressions use a slightly different syntax, although most of the core code can be reused with a bit of thought. This is also the reason why I am not moving the parsing or dwarf generation bits, as they will need to be generalized a bit before they're usable for both scenarios. This patch should be NFC, modulo renaming the moved entities to more neutral names. The reason I am moving this to the "Symbol" library, is because both customers will be "Symbol"Files, and also the unwinding code lives in the Symbol library. From a purely dependency standpoint this code will probably be standalone, and so it could be moved all the way to Utility, but that seems too low for this kind of functionality. Reviewers: jasonmolenda, amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D60599 llvm-svn: 358976
* [NativePDB] Add anonymous namespaces supportAleksandr Urakov2019-04-222-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds anonymous namespaces support to the native PDB plugin. I had to reference from the main function variables of the types that are inside of the anonymous namespace to include them in debug info. Without the references they are not included. I think it's because they are static, then are visible only in the current translation unit, so they are not needed without any references to them. There is also the problem case with variables of types that are nested in template structs. For now I've left FIXME in the test because this case is not related to the change. Reviewers: zturner, asmith, labath, stella.stamenova, amccarth Reviewed By: amccarth Subscribers: zloyrobot, aprantl, teemperor, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D60817 llvm-svn: 358873
* [lldb] Don't filter variable list when doing a lookup by mangled name in ↵Kuba Mracek2019-04-181-1/+3
| | | | | | | | SymbolFileDWARF::FindGlobalVariables Differential Revision: https://reviews.llvm.org/D60737 llvm-svn: 358629
* Fix compiler warning introduced by r358261Pavel Labath2019-04-121-0/+2
| | | | | | Add a virtual destructor to the class with virtual methods. llvm-svn: 358284
* PDBFPO: Improvements to the AST visitorPavel Labath2019-04-121-138/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch attempts to solve two issues made this code hard to follow for me. The first issue was that a lot of what these visitors do is mutate the AST. The visitor pattern is not particularly good for that because by the time you have performed the dynamic type dispatch, it's too late to go back to the parent node, and change its pointer. The previous code dealt with that relatively elegantly, but it still meant that one had to perform manual type checks, which is what the visitor pattern is supposed to avoid. The second issue was not being able to return values from the Visit functions, which meant that one had to store function results in member variables (a common problem with visitor patterns). Here, I solve both problems by making the visitor use a type switch instead of going through double dispatch on the visited object. This allows one to parameterize the visitor based on the return type and pass function results as function results. The mutation is fascilitated by having each Visit function take two arguments -- a reference to the object itself (with the correct dynamic type), and a reference to the parent's pointer to this object. Although this wasn't my explicit goal here, the fact that we're not using virtual dispatch anymore allows us to make the AST nodes trivially destructible, which is a good thing, since we were not destroying them anyway. Reviewers: aleksandr.urakov, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60410 llvm-svn: 358261
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-1030-272/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* PDBFPO: add dyn_cast supportPavel Labath2019-04-081-7/+25
| | | | | | | This adds the necessary glue so we can use llvm::dyn_cast, instead of doing a manual type-check followed by a cast. NFC. llvm-svn: 357895
* PDBFPO: Use references instead of pointers, where possiblePavel Labath2019-04-051-65/+63
| | | | | | | | | | | | | | | | | | | Summary: The code was passing pointers around, expecting they would be not null. In c++ it is possible to convey this notion explicitly by using a reference instead. Not all uses of pointers could be converted to references (e.g. one can't store references in a container), but this will at least make it locally obvious that code is dealing with nonnull pointers. Reviewers: aleksandr.urakov, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60271 llvm-svn: 357744
* Add dropped ManualDWARFIndex assert()Jan Kratochvil2019-04-041-0/+3
| | | | | | | | D47253 dropped this assertion. Differential Revision: https://reviews.llvm.org/D60254 llvm-svn: 357678
* [codeview] Remove Type member from CVRecordReid Kleckner2019-04-041-1/+1
| | | | | | | | | | | | | | | | | Summary: Now CVType and CVSymbol are effectively type-safe wrappers around ArrayRef<uint8_t>. Make the kind() accessor load it from the RecordPrefix, which is the same for types and symbols. Reviewers: zturner, aganea Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60018 llvm-svn: 357658
* [NativePDB] Don't fail on import modules.Zachary Turner2019-04-021-2/+11
| | | | | | | | | | | A recent patch to LLD started emitting information about import modules. These are represented as compile units in the PDB, but with no additional debug info. This was confusing the native pdb reader, who expected that the debug info stream be present. This should fix failing tests on the Windows bots. llvm-svn: 357513
* PDBFPO: Refactor register reference resolutionPavel Labath2019-04-021-60/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This refactors moves the register name->number resolution out of the FPOProgramNodeRegisterRef class. Instead I create a special FPOProgramNodeSymbol class, which holds unresolved symbols, and move the resolution into the ResolveRegisterRefs visitor. The background here is that I'd like to use this code for Breakpad unwind info, which uses similar syntax to describe unwind info. For example, a simple breakpad unwind program might look like: .cfa: $esp 8 + $ebp: .cfa 8 - ^ To be able to do this, I need to be able to customize register resolving, as that is presently hardcoded to use codeview register names, but breakpad supports a lot more architectures with different register names. Moving the resolution into a separate class will allow each user to use a different resolution logic. Reviewers: aleksandr.urakov, zturner, amccarth Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D60068 llvm-svn: 357455
* Kill unused variable m_tu_decl_up in SymbolFilePDBNathan Lanza2019-03-272-10/+1
| | | | | | | | | | | | | | | | | | Summary: An TranslationUnitDecl was being brought in from the clang::ASTContext which required clang specific code to exist in SymbolFilePDB. Since it was unused we can just get rid of it along with the clang specific code. Reviewers: rnk, zturner, compnerd Reviewed By: compnerd Subscribers: jdoerfert Differential Revision: https://reviews.llvm.org/D59804 llvm-svn: 357113
* Fix a "memset clearing an object of non-trivial type" warning in DWARFFormValuePavel Labath2019-03-271-1/+1
| | | | | | | | This is diagnosed by gcc-8. The ValueType struct already has a default constructor which performs zero-initialization, so we can just call that instead of using memset. llvm-svn: 357056
* Get the lang from the CompileUnit for ParseCompileUnitFunctionForPDBFuncNathan Lanza2019-03-271-1/+2
| | | | | | | | | | | | Summary: Instead of assuming that the language is C++ instead check the compunit for the language it received from the debug info. Subscribers: aprantl, jdoerfert Differential Revision: https://reviews.llvm.org/D59805 llvm-svn: 357044
* Revert "Move the rest of the sections over to DWARFContext."Pavel Labath2019-03-2217-327/+270
| | | | | | | | | | This reverts commit r356682 because it breaks the DWO flavours of some tests: lldb-Suite :: lang/c/const_variables/TestConstVariables.py lldb-Suite :: lang/c/local_variables/TestLocalVariables.py lldb-Suite :: lang/c/vla/TestVLA.py llvm-svn: 356773
* Move the rest of the sections over to DWARFContext.Zachary Turner2019-03-2117-270/+327
| | | | | | | | | This is mostly mechanical, and just moves the remaining non-DWO related sections over to DWARFContext. Differential Revision: https://reviews.llvm.org/D59611 llvm-svn: 356682
* Introduce DWARFContext.Zachary Turner2019-03-208-54/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM's DWARF parsing library has a class called DWARFContext which holds all of the various DWARF data sections and lots of other information. LLDB's on the other hand stores all of this directly in SymbolFileDWARF / SymbolFileDWARFDwo and passes this interface around through the parsing library. Obviously this is incompatible with a world where the low level interface does not depend on the high level interface, so we need to move towards a model similar to LLVM's - i.e. all of the context needed for low level parsing should be in a single class, and that class gets passed around. This patch is a small incremental step towards achieving this. The interface and internals deviate from LLVM's for technical reasons, but the high level idea is the same. The goal is, eventually, to remove all occurrences of SymbolFileDWARF from the low level parsing code. For now I've chosen a very simple section - the .debug_aranges section to move into DWARFContext while leaving everything else unchanged. In the short term this is a bit confusing because now the information you need might come from either of 2 different locations. But it's a huge refactor to do this all at once and runs a much higher risk of breaking things. So I think it would be wise to do this in very small pieces. TL;DR - No functional change Differential Revision: https://reviews.llvm.org/D59562 llvm-svn: 356612
* Delete more dead code.Zachary Turner2019-03-1921-318/+11
| | | | | | | | All of this is code that is unreferenced. Removing as much of this as possible makes it more easy to determine what functionality is missing and/or shared between LLVM and LLDB's DWARF interfaces. llvm-svn: 356509
* Remove some dead DWARF enum -> string conversion functions.Zachary Turner2019-03-192-258/+0
| | | | llvm-svn: 356495
* Delete dead code.Zachary Turner2019-03-1923-716/+1
| | | | | | | | | | Most of these are Dump functions that are never called, but there is one instance of entire unused classes (DWARFDebugMacinfo and DWARFDebugMacinfoEntry) which are also unreferenced in the codebase). Differential Revision: https://reviews.llvm.org/D59276 llvm-svn: 356490
* Remove a couple of log statements.Zachary Turner2019-03-193-60/+1
| | | | | | | | | | | | | These log statements have questionable value, and hinder the effort of separating the high and low level DWARF parsing interfaces inside of LLDB. Removing them for now, and if/when we need such log statements again in the future, we can add them back (if possible) or introduce a mechanism for logging from the low-level interface in such a way that it isn't coupled to the high level interface. Differential Revision: https://reviews.llvm.org/D59498 llvm-svn: 356469
* Abbreviation declarations are required to have non-null tags.Zachary Turner2019-03-151-5/+3
| | | | | | Treat a null tag as an error. llvm-svn: 356284
OpenPOWER on IntegriCloud