summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile
Commit message (Collapse)AuthorAgeFilesLines
...
* Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.Zachary Turner2019-01-1010-46/+37
| | | | | | | | | | | | | | | | | | | | | | | | | The function SymbolFile::ParseTypes previously accepted a SymbolContext. This makes it extremely difficult to implement faithfully, because you have to account for all possible combinations of members being set in the SymbolContext. On the other hand, no clients of this function actually care about implementing this function to this strict of a standard. AFAICT, there is actually only 1 client in the entire codebase, and it is the function ParseAllDebugSymbols, which is itself only called for testing purposes when dumping information. At this call-site, the only field it sets is the CompileUnit, meaning that an implementer of a SymbolFile need not worry about any examining or handling any other fields which might be set. By restricting this API to accept exactly a CompileUnit& and nothing more, we can simplify the life of new SymbolFile plugin implementers by making it clear exactly what the necessary and sufficient set of functionality they need to implement is, while at the same time removing some dead code that tried to handle other types of SymbolContext fields that were never going to be set anyway. Differential Revision: https://reviews.llvm.org/D56462 llvm-svn: 350889
* [NativePDB] Add support for parsing typedef records.Zachary Turner2019-01-106-61/+273
| | | | | | | | | | | | | | | | | | | | Typedefs are represented as S_UDT records in the globals stream. This creates a strange situation where "types" are actually represented as "symbols", so they need special handling. In order to test this, we don't just use lldb and print out some variables causing the AST to get created, because variables whose type is a typedef will have debug info referencing the original type, not the typedef. So we use lldb-test instead which will parse all debug info in the entire file. This exposed some problems with lldb-test and the native reader, mainly that certain types of obscure symbols which we can find when iterating every single record would trigger crashes. These have been fixed as well so that lldb-test can be used to test this functionality. Differential Revision: https://reviews.llvm.org/D56461 llvm-svn: 350888
* Change lldb-test to use ParseAllDebugSymbols.Zachary Turner2019-01-092-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ParseDeclsForContext was originally created to serve the very specific case where the context is a function block. It was never intended to be used for arbitrary DeclContexts, however due to the generic name, the DWARF and PDB plugins implemented it in this way "just in case". Then, lldb-test came along and decided to use it in that way. Related to this, there are a set of functions in the SymbolFile class interface whose requirements and expectations are not documented. For example, if you call ParseCompileUnitFunctions, there's an inherent requirement that you create entries in the underlying clang AST for these functions as well as their signature types, because in order to create an lldb_private::Function object, you have to pass it a CompilerType for the parameter representing the signature. On the other hand, there is no similar requirement (either inherent or documented) if one were to call ParseDeclsForContext. Specifically, if one calls ParseDeclsForContext, and some variable declarations, types, and other things are added to the clang AST, is it necessary to create lldb::Variable, lldb::Type, etc objects representing them? Nobody knows. There is, however, an accidental requirement, because since all of the plugins implemented this just in case, lldb-test came along and used ParsedDeclsForContext, and then wrote check lines that depended on this. When I went to try and implemented the NativePDB reader, I did not adhere to this (in fact, from a layering perspective I went out of my way to avoid it), and as a result the existing DIA PDB tests don't work when the native PDB reader is enabled, because they expect that calling ParseDeclsForContext will modify the *module's* view of symbols, and not just the internal AST. All of this confusion, however, can be avoided if we simply stick to using ParseDeclsForContext for its original intended use case (blocks), and use a different function (ParseAllDebugSymbols) for its intended use case which is, unsuprisingly, to parse all the debug symbols (which is all lldb-test really wanted to do anyway). In the future, I would like to change ParseDeclsForContext to ParseDeclsForFunctionBlock, then delete all of the dead code inside that handles other types of DeclContexts (and probably even assert if the DeclContext is anything other than a block). A few PDB tests needed to be fixed up as a result of this, and this also exposed a couple of bugs in the DIA PDB reader (doesn't matter much since it should be going away soon, but worth mentioning) where the appropriate AST entries weren't being created always. Differential Revision: https://reviews.llvm.org/D56418 llvm-svn: 350764
* [PdbAstBuilder] Remove unused functionsJonas Devlieghere2019-01-081-17/+0
| | | | | | | PdbAstBuilder.cpp:273:20: warning: unused function 'GetParentUniqueName' [-Wunused-function] PdbAstBuilder.cpp:267:13: warning: unused function 'IsUniqueNameEnumTag' [-Wunused-function] llvm-svn: 350652
* Convert to LLDB coding style (NFC)Adrian Prantl2019-01-081-7/+7
| | | | llvm-svn: 350651
* Simplify code.Adrian Prantl2019-01-071-2/+1
| | | | llvm-svn: 350577
* Clarify comment and variable names. (NFC)Adrian Prantl2019-01-071-5/+7
| | | | llvm-svn: 350576
* Rename DWARFDIE::GetDWOContext() -> GetDeclContext() (NFC)Adrian Prantl2019-01-074-5/+8
| | | | | | Despite the name, this function has nothing to do with the DWO format. llvm-svn: 350575
* RangeMap.h: merge RangeDataArray and RangeDataVectorPavel Labath2019-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main difference between the classes was supposed to be the fact that one is backed by llvm::SmallVector, and the other by std::vector. However, over the years, they have accumulated various other differences too. This essentially removes the std::vector version, as that is pretty much identical to llvm::SmallVector<T, 0>, and combines their interfaces. It does not attempt to do a more significant refactoring, even though there is still a lot of duplication in this file, as it is hard to tell which quirk of some API is depended on by somebody (and, a previous, more ambitious attempt at this in D16769 has failed). I also add some tests, including one which demonstrates one of the quirks/bugs of the API I have noticed in the process. Reviewers: clayborg, teemperor, tberghammer Subscribers: mgorny, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56170 llvm-svn: 350380
* Simplify ObjectFile::GetArchitecturePavel Labath2019-01-031-3/+1
| | | | | | | | | | | | | | | | Summary: instead of returning the architecture through by-ref argument and a boolean value indicating success, we can just return the ArchSpec directly. Since the ArchSpec already has an invalid state, it can be used to denote the failure without the additional bool. Reviewers: clayborg, zturner, espindola Subscribers: emaste, arichardson, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56129 llvm-svn: 350291
* Try to fix Green Dragon bot.Zachary Turner2019-01-021-2/+2
| | | | | | | It doesn't like this std::tie() for some reason, hopefuly this fixes it. llvm-svn: 350262
* Use map::insert instead of try_emplace.Zachary Turner2019-01-021-1/+1
| | | | | | try_emplace is C++17. llvm-svn: 350244
* [NativePDB] Implement ParseDeclsForContext.Zachary Turner2019-01-026-50/+442
| | | | | | | | | | | This is a first step towards getting lldb-test symbols working with the native plugin. There is a remaining issue, which is that the plugin expects that ParseDeclsForContext will also create lldb symbols rather than just the decls, but the native pdb plugin doesn't currently do this. This will be addressed in a followup patch. llvm-svn: 350243
* [NativePDB] Fix setting breakpoint by file and line.Zachary Turner2019-01-023-1/+30
| | | | | | | | | | | | | | | | | | | There were several problems preventing this from working. The first is that when the PDB had an absolute path to the main source file, we would construct an invalid path by prepending the compilation directory to it anyway. So we needed to check if the path is already absolute first. Second, LLDB assumes that the zero'th item in the support file list is the main compilation unit. We were respecting this requirement, but LLDB *also* requires that file to appear somewhere in the list starting from index 1 as well. So the main compilation file should appear in the support file list twice. And when parsing a line table, it expects the LineEntry records to be constructed using the 1-based index. With these two fixes we can now set breakpoints by file and line using the native PDB reader. llvm-svn: 350240
* [DWARFUnit] Remove commented out code. NFCI.Davide Italiano2018-12-311-7/+0
| | | | llvm-svn: 350177
* DWARF: Fix a bug in array size computationPavel Labath2018-12-272-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r346165 introduced a bug, where we would fail to parse the size of an array if that size happened to match an existing die offset. The logic was: if (DWARFDIE count = die.GetReferencedDie(DW_AT_count)) num_elements = compute_vla_size(count); else num_elements = die.GetUsigned(DW_AT_count); // a fixed-size array The problem with this logic was that GetReferencedDie did not take the form class of the attribute into account, and would happily return a die reference for any form, if its value happened to match some die. As this behavior is inconsistent with how llvm's DWARFFormValue class operates, I chose to fix the problem by making our version of this class match the llvm behavior. For this to work, I had to add an explicit form class check to the .apple_XXX tables parsing code, because they do (incorrectly?) use data forms as die references. Reviewers: aprantl, clayborg Subscribers: JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D55991 llvm-svn: 350086
* [NativePDB] Create VarDecls for global variables.Zachary Turner2018-12-206-7/+56
| | | | | | | | | | Previously we would create these for local variables but not for global variables. Also updated existing tests which created global variables to check for them in the resulting AST. llvm-svn: 349854
* [NativePDB] Fix a use after free and enable corresponding native test.Zachary Turner2018-12-191-1/+1
| | | | | | | | | | | We had a use after free where we were assigning the result of a function that returned a string to a StringRef. After fixing this use after free, one of the DIA PDB tests now passes with the native PDB reader, so we enable the test under native mode as well. The goal is to eventually make all the tests pass under both, at which point we can disable them all under DIA mode. llvm-svn: 349673
* [NativePDB] Correctly reconstruct DeclContext for nested enums.Zachary Turner2018-12-181-1/+4
| | | | | | | | | | | | We reconstruct the AST hierarchy by trying to hack up a mangled name for the parent type using the child type's mangled name. This was failing for enums because their tag type is represented with two letters ("W4") instead of one letter ("T", "U", etc) as it is with classes, structs, and unions. After accounting for this we can now correctly determine when an enum is nested inside of a namespace or a class. llvm-svn: 349565
* Fix typo in r349473Luke Cheeseman2018-12-181-1/+1
| | | | llvm-svn: 349474
* Update CallFrameString API to account for r349472Luke Cheeseman2018-12-182-3/+3
| | | | | | | - CallFrameString now takes an Arch parameter to account for multiplexing overlapping CFI directives llvm-svn: 349473
* Fix case of source file in CMakeLists.txtZachary Turner2018-12-171-1/+1
| | | | llvm-svn: 349399
* [NativePDB] Decouple AST reconstruction from lldb Symbol creation.Zachary Turner2018-12-179-806/+1366
| | | | | | | | | | | | Previously the code that parsed debug info to create lldb's Symbol objects such as Variable, Type, Function, etc was tightly coupled to the AST reconstruction code. This made it difficult / impossible to implement functions such as ParseDeclsForContext() that were only supposed to be operating on clang AST's. By splitting these apart, the logic becomes much cleaner and we have a clear separation of responsibilities. llvm-svn: 349383
* Simplify Boolean expressionsJonas Devlieghere2018-12-156-25/+17
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* Remove unused variable.Richard Trieu2018-12-141-1/+0
| | | | llvm-svn: 349128
* [NativePDB] Add support for local variables.Zachary Turner2018-12-135-67/+904
| | | | | | | | | This patch adds support for parsing and evaluating local variables. using the native pdb plugin. Differential Revision: https://reviews.llvm.org/D55575 llvm-svn: 349067
* NFC: fix compiler warning about code never being executed when compiling on ↵Greg Clayton2018-12-121-3/+4
| | | | | | non windows platform. llvm-svn: 348951
* [ast] CreateParameterDeclaration should use an appropriate DeclContext.Zachary Turner2018-12-123-5/+7
| | | | | | | | | | | | | | | | | | Previously CreateParameterDeclaration was always using the translation unit DeclContext. We would later go and add parameters to the FunctionDecl, but internally clang makes a copy when you do this, and we'd end up with ParmVarDecl's at the global scope as well as in the function scope. This fixes the issue. It's hard to say whether this will introduce a behavioral change in name lookup, but I know there have been several hacks introduced in previous years to deal with collisions between various types of variables, so there's a chance that this patch could obviate one of those hacks. Differential Revision: https://reviews.llvm.org/D55571 llvm-svn: 348941
* [NativePDB] Reconstruct function declarations from debug info.Zachary Turner2018-12-072-6/+135
| | | | | | | | | | | | Previously we would create an lldb::Function object for each function parsed, but we would not add these to the clang AST. This is a first step towards getting local variable support working, as we first need an AST decl so that when we create local variable entries, they have the proper DeclContext. Differential Revision: https://reviews.llvm.org/D55384 llvm-svn: 348631
* [PDB] Move some code around. NFC.Zachary Turner2018-12-066-245/+333
| | | | llvm-svn: 348505
* Support skewed stream arrays.Zachary Turner2018-12-061-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VarStreamArray was built on the assumption that it is backed by a StreamRef, and offset 0 of that StreamRef is the first byte of the first record in the array. This is a logical and intuitive assumption, but unfortunately we have use cases where it doesn't hold. Specifically, a PDB module's symbol stream is prefixed by 4 bytes containing a magic value, and the first byte of record data in the array is actually at offset 4 of this byte sequence. Previously, we would just truncate the first 4 bytes and then construct the VarStreamArray with the resulting StreamRef, so that offset 0 of the underlying stream did correspond to the first byte of the first record, but this is problematic, because symbol records reference other symbol records by the absolute offset including that initial magic 4 bytes. So if another record wants to refer to the first record in the array, it would say "the record at offset 4". This led to extremely confusing hacks and semantics in loading code, and after spending 30 minutes trying to get some math right and failing, I decided to fix this in the underlying implementation of VarStreamArray. Now, we can say that a stream is skewed by a particular amount. This way, when we access a record by absolute offset, we can use the same values that the records themselves contain, instead of having to do fixups. Differential Revision: https://reviews.llvm.org/D55344 llvm-svn: 348499
* [PDB] Support PDB-backed expressions evaluation (+ fix stuck test)Aleksandr Urakov2018-12-033-27/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch contains several small fixes, which makes it possible to evaluate expressions on Windows using information from PDB. The changes are: - several sanitize checks; - make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic value on a failure, because callers wait 0 in this case; - entry point required to be a file address, not RVA, in the ObjectFilePECOFF; - do not crash on a debuggee second chance exception - it may be an expression evaluation crash. Also fix detection of "crushed" threads in tests; - create parameter declarations for functions in AST to make it possible to call debugee functions from expressions; - relax name searching rules for variables, functions, namespaces and types. Now it works just like in the DWARF plugin; - fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc. Reviewers: zturner, asmith, stella.stamenova Reviewed By: stella.stamenova, asmith Tags: #lldb Differential Revision: https://reviews.llvm.org/D53759 llvm-svn: 348136
* Revert "[PDB] Support PDB-backed expressions evaluation"Stella Stamenova2018-11-303-61/+27
| | | | | | | | | This reverts commit dec87759523b2f22fcff3325bc2cd543e4cda0e7. This commit caused the tests on Windows to run forever rather than complete. Reverting until the commit can be fixed to not stall. llvm-svn: 348009
* [PDB] Support PDB-backed expressions evaluationAleksandr Urakov2018-11-303-27/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch contains several small fixes, which makes it possible to evaluate expressions on Windows using information from PDB. The changes are: - several sanitize checks; - make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic value on a failure, because callers wait 0 in this case; - entry point required to be a file address, not RVA, in the ObjectFilePECOFF; - do not crash on a debuggee second chance exception - it may be an expression evaluation crash; - create parameter declarations for functions in AST to make it possible to call debugee functions from expressions; - relax name searching rules for variables, functions, namespaces and types. Now it works just like in the DWARF plugin; - fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc. Reviewers: zturner, asmith, stella.stamenova Reviewed By: stella.stamenova, asmith Tags: #lldb Differential Revision: https://reviews.llvm.org/D53759 llvm-svn: 347962
* [Symbol] Search symbols with name and type in a symbol fileAleksandr Urakov2018-11-302-0/+54
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file, not only in a symtab. It is helpful when working with PE, because PE's symtabs contain only imported / exported symbols only. Such a search is required for e.g. evaluation of an expression that calls some function of the debuggee. Reviewers: zturner, asmith, labath, clayborg, espindola Reviewed By: clayborg Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53368 llvm-svn: 347960
* [LLDB] - Improve the support of .debug_str_offsets/.debug_str_offsets.dwoGeorge Rimar2018-11-293-20/+46
| | | | | | | | | | | | | | | | | A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute that points to the first string offset of the CU contribution to the .debug_str_offsets. At the same time, when we use split dwarf, the corresponding split debug unit also may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo. In that case, DWO does not contain DW_AT_str_offsets_base, but LLDB still need to know and skip the .debug_str_offsets.dwo section header to access the offsets. The patch implements the support of DW_AT_str_offsets_base. Differential revision: https://reviews.llvm.org/D54844 llvm-svn: 347859
* [LLDB] - Fix setting the breakpoints when -gsplit-dwarf and DWARF 5 were ↵George Rimar2018-11-291-4/+14
| | | | | | | | | | | | | | | | used for building the executable. The issue happens because starting from DWARF v5 DW_AT_addr_base attribute should be used instead of DW_AT_GNU_addr_base. LLDB does not do that and we end up reading the .debug_addr header as section content (as addresses) instead of skipping it and reading the real addresses. Then LLDB is unable to match 2 similar locations and thinks they are different. Differential revision: https://reviews.llvm.org/D54751 llvm-svn: 347842
* Move time cast to SymbolFileDWARFDebugMapJonas Devlieghere2018-11-271-6/+6
| | | | | | | | | When trying to fix the bots we expected that the cast would be needed in different places. Ultimately it turned out only the SymbolFileDWARFDebugMap was affected so, as Pavel correctly notes, it makes more sense to do the cast just there instead of in teh FS. llvm-svn: 347660
* [FileSystem] Ignore nanoseconds when comparing oso_mod_timeJonas Devlieghere2018-11-261-1/+2
| | | | | | | | | | | After a recent change in LLVM the TimePoint encoding become more precise, exceeding the precision of the TimePoint obtained from the DebugMap. This patch adds a flag to the GetModificationTime helper in the FileSystem to return the modification time with less precision. Thanks to Davide for bisecting this failure on the LLDB bots. llvm-svn: 347615
* Revert r347491 as it's llvm counterpart breaks buildbotsLuke Cheeseman2018-11-232-3/+3
| | | | llvm-svn: 347500
* Revert r343342 together with LLVM commit 347490.Luke Cheeseman2018-11-232-3/+3
| | | | llvm-svn: 347491
* [SymbolFile] Remove unused function. NFCI.Davide Italiano2018-11-161-18/+0
| | | | llvm-svn: 347084
* Don't use uniform initialization syntax.Zachary Turner2018-11-163-11/+21
| | | | llvm-svn: 347020
* [NativePDB] Rewrite the PdbSymUid to use our own custom namespacing scheme.Zachary Turner2018-11-1613-411/+435
| | | | | | | | | | | | | | | | | | | | | | | Originally we created our 64-bit UID scheme by using the first byte as sort of a "tag" to represent what kind of symbol this was, and we re-used the PDB_SymType enumeration for this. For native pdb support, this is not really the right abstraction layer, because what we really want is something that tells us *how* to find the symbol. This means, specifically, is in the globals stream / public stream / module stream / TPI stream / etc, and for whichever one it is in, where is it within that stream? A good example of why the old namespacing scheme was insufficient is that it is more or less impossible to create a uid for a field list member of a class/struction/union/enum that tells you how to locate the original record. With this new scheme, the first byte is no longer a PDB_SymType enum but a new enum created specifically to identify where in the PDB this record lives. This gives us much better flexibility in what kinds of symbols the uids can identify. llvm-svn: 347018
* [LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.".George Rimar2018-11-143-13/+42
| | | | | | | | | | | | | | | | | | | | | | | | | Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
* Revert r346848 "[LLDB] - Support the single file split DWARF."George Rimar2018-11-143-42/+13
| | | | | | | It broke BB: http://green.lab.llvm.org/green/job/lldb-cmake/12522/testReport/junit/LLDB/Breakpoint/single_file_split_dwarf_test/ llvm-svn: 346853
* Fix a crash when parsing incorrect DWARFPavel Labath2018-11-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While parsing a childless compile unit DIE we could crash if the DIE was followed by any extra data (such as a superfluous end-of-children marker). This happened because the break-on-depth=0 check was performed only when parsing the null DIE, which was not correct because with a childless root DIE, we could reach the end of the unit without ever encountering the null DIE. If the compile unit contribution ended directly after the CU DIE, everything would be fine as we would terminate parsing due to reaching EOF. However, if the contribution contained extra data (perhaps a superfluous end-of-children marker), we would crash because we would treat that data as the begging of another compile unit. This fixes the crash by moving the depth=0 check to a more generic place, and also adds a regression test. Reviewers: clayborg, jankratochvil, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D54417 llvm-svn: 346849
* [LLDB] - Support the single file split DWARF.George Rimar2018-11-143-13/+42
| | | | | | | | | | | | | | | | | | DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52296 llvm-svn: 346848
* [NativePDB] Add support for S_CONSTANT records.Zachary Turner2018-11-132-8/+134
| | | | | | | | | | | | | | | | | clang-cl does not emit these, but MSVC does, so we need to be able to handle them. Because clang-cl does not generate them, it was a bit hard to write a test. So what I had to do was get an PDB file with some S_CONSTANT records in using cl and link, dump it using llvm-pdbutil dump -globals -sym-data to get the bytes of the records, generate the same object file using clang-cl but with -S to emit an assembly file, and replace all the S_LDATA32 records with the bytes of the S_CONSTANT records. This way, we can compile the file using llvm-mc and link it with lld-link. Differential Revision: https://reviews.llvm.org/D54452 llvm-svn: 346787
* [NativePDB] Improved support for nested type reconstruction.Zachary Turner2018-11-131-4/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a previous patch, we pre-processed the TPI stream in order to build the reverse mapping from nested type -> parent type so that we could accurately reconstruct a DeclContext hierarchy. However, there were some issues. An LF_NESTTYPE record is really just a typedef, so although it happens to be used to indicate the name of the nested type and referring to the global record which defines the type, it is also used for every other kind of nested typedef. When we rebuild the DeclContext hierarchy, we want it to be as accurate as possible, which means that if we have something like: struct A { struct B {}; using C = B; }; We don't want to create two CXXRecordDecls in the AST each with the exact same definition. We just want to create one for B and then define C as an alias to B. Previously, however, it would not be able to distinguish between the two cases and it would treat A::B and A::C as being two classes each with separate definitions. We address the first half of improving the pre-processing logic so that only actual definitions are treated this way. Later, in a followup patch, we can handle the case of nested typedefs since we're already going to be enumerating the field list anyway and this patch introduces the general framework for distinguishing between the two cases. Differential Revision: https://reviews.llvm.org/D54357 llvm-svn: 346786
OpenPOWER on IntegriCloud