summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFC] Remove all unnecessary includes for ClangASTSourceCommon.hRaphael Isemann2019-12-171-1/+0
| | | | | These files only need the definition of ClangASTMetadata (which was previously in the ClangASTSourceCommon.h) or don't need the include at all.
* [lldb] Don't put compile unit name into the support file list and support ↵Pavel Labath2019-12-051-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARF5 line tables Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954
* Replace bitfield in lldb::Type with byte-sized members. (NFC)Adrian Prantl2019-11-181-11/+11
| | | | | | Due to alginment and packing using separate members takes up the same amount of space, but makes it far less cumbersome to deal with it in constructors etc.
* Add RTTI support to the SymbolFile class hierarchyAdrian Prantl2019-11-151-0/+2
| | | | Differential Revision: https://reviews.llvm.org/D70322
* Performance: Add a set of visited SymbolFiles to the other FindFiles variant.Adrian Prantl2019-11-121-2/+3
| | | | | | | | | | | | | | This is basically the same bug as in r260434. SymbolFileDWARF::FindTypes has exponential worst-case when digging through dependency DAG of .pcm files because each object file and .pcm file may depend on an already-visited .pcm file, which may again have dependencies. Fixed here by carrying a set of already visited SymbolFiles around. rdar://problem/56993424 Differential Revision: https://reviews.llvm.org/D70106
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-171-12/+7
| | | | | | | | | | | | This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
* [NativePDB] Remove unused references to ClangASTImporterAlex Langford2019-10-111-1/+0
| | | | llvm-svn: 374587
* Remove size_t return parameter from FindTypesAdrian Prantl2019-10-011-22/+13
| | | | | | | | | | | | | | | In r368345 I accidentally introduced a regression that would over-report the number of matches found by FindTypes if the DeclContext Filter was hit. This patch simply removes the size_t return parameter altogether — it's not that useful. rdar://problem/55500457 Differential Revision: https://reviews.llvm.org/D68169 llvm-svn: 373344
* Remove unused "append" parameter from FindTypes APIAdrian Prantl2019-09-301-7/+2
| | | | | | | | | | | | | I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it incorrectly (passing append=false in a for-loop to recursive calls to FindTypes would yield only the very last set of results), but instead of fixing it, removing it seemed like an even better option. rdar://problem/54412692 Differential Revision: https://reviews.llvm.org/D68171 llvm-svn: 373224
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-1/+4
| | | | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
* Revert Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-4/+1
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-1/+4
| | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
* Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl2019-08-211-3/+2
| | | | | | | | | | | | | | | This patch generalizes the FindTypes with CompilerContext interface to support looking up a type of unknown kind by name, as well as looking up a type inside an unspecified submodule. These features are motivated by the Swift branch, but are fully tested via unit tests and lldb-test on llvm.org. Specifically, this patch adds an AnyModule and an AnyType CompilerContext kind. Differential Revision: https://reviews.llvm.org/D66507 rdar://problem/54471165 llvm-svn: 369555
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-4/+4
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* Add llvm-style RTTI to ObjectFile hierarchyPavel Labath2019-07-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-311-12/+12
| | | | | | | | | | | | | | | | | | 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
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-301-10/+17
| | | | | | | | | | | | | | | | | | 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
* SymbolVendor: Move locking into the Symbol FilesPavel Labath2019-07-301-0/+12
| | | | | | | | | | | | | | | | | | | | | | 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
* SymbolVendor: Remove the type list memberPavel Labath2019-07-251-3/+3
| | | | | | | | | | | | | | | | | | | | | Summary: Similarly to the compile unit lists, the list of types can also be managed by the symbol file itself. Since the only purpose of this list seems to be to maintain an owning reference to all the types a symbol file has created (items are only ever added to the list, never retrieved), I remove the passthrough functions in SymbolVendor and Module. I also tighten the interface of the function (return a reference instead of a pointer, make it protected instead of public). Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65135 llvm-svn: 366994
* SymbolVendor: Move compile unit handling into the SymbolFile classPavel Labath2019-07-231-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SymbolFile classes are responsible for creating CompileUnit instances and they already need to have a notion of the id<->CompileUnit mapping (because of APIs like ParseCompileUnitAtIndex). However, the SymbolVendor has remained as the thing responsible for caching created units (which the SymbolFiles were calling via convoluted constructs like "m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)"). This patch moves the responsibility of caching the units into the SymbolFile class. It does this by moving the implementation of SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the equivalent SymbolFile functions. The SymbolVendor functions become just a passthrough much like the rest of SymbolVendor. The original implementations of SymbolFile::GetNumCompileUnits is moved to "CalculateNumCompileUnits", and are made protected, as the "Get" function is the external api of the class. SymbolFile::ParseCompileUnitAtIndex is made protected for the same reason. This is the first step in removing the SymbolVendor indirection, as proposed in <http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After removing all interesting logic from the SymbolVendor class, I'll proceed with removing the indirection itself. Reviewers: clayborg, jingham, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65089 llvm-svn: 366791
* [NativePDB] Make GetOrCreateDeclForUid return an lldb CompilerDeclNathan Lanza2019-07-211-3/+4
| | | | | | | | | We intend to make PdbAstBuilder abstract and implement PdbAstBuilderClang along with any other languages that wish to use PDBs. Thus, change GetOrCreateDeclForUid from returning a clang decl to a lldb_private::CompilerDecl. llvm-svn: 366650
* [NativePDB] Support member function types in PdbAstBuilderAleksandr Urakov2019-05-131-0/+16
| | | | | | | | | | | | | | | | | 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
* Add a case in SymbolFile{Native,}PDB::TranslateLanguage for SwiftNathan Lanza2019-03-111-0/+2
| | | | | | | | | | Summary: see above Reviewers: compnerd Differential Revision: https://reviews.llvm.org/D59230 llvm-svn: 355883
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-4/+4
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* PECOFF: Implement GetBaseAddressPavel Labath2019-02-181-1/+1
| | | | | | | | | | | | | | | | | | COFF files are modelled in lldb as having one big container section spanning the entire module image, with the actual sections being subsections of that. In this model, the base address is simply the address of the first byte of that section. This also removes the hack where ObjectFilePECOFF was using the m_file_offset field to communicate this information. Using file offset for this purpose is completely wrong, as that is supposed to indicate where is this ObjectFile located in the file on disk. This field is only meaningful for fat binaries, and should normally be 0. Both PDB plugins have been updated to use GetBaseAddress instead of GetFileOffset. llvm-svn: 354258
* Deserialize Clang module search path from DWARFAdrian Prantl2019-02-131-1/+1
| | | | | | | | | | | | This patch properly extracts the full submodule path as well as its search paths from DWARF import decls and passes it on to the ClangModulesDeclVendor. rdar://problem/47970144 Differential Revision: https://reviews.llvm.org/D58090 llvm-svn: 353961
* [PDB] Fix location retrieval for function local variables and arguments that areAleksandr Urakov2019-02-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | stored relative to VFRAME Summary: This patch makes LLDB able to retrieve proper values for function arguments and local variables stored in PDB relative to VFRAME register. Patch contains retrieval of corresponding FPO table entries from PDB and a generic translator from FPO programs to DWARF expressions to get correct VFRAME value. Patch also improves variables-locations.test and makes this test passable on x86. Patch By: leonid.mashinsky Reviewers: zturner, asmith, stella.stamenova, aleksandr.urakov Reviewed By: zturner Subscribers: arphaman, labath, mgorny, aprantl, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D55122 llvm-svn: 352845
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-141-4/+3
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* [SymbolFile] Remove the SymbolContext parameter from FindNamespace.Zachary Turner2019-01-141-2/+1
| | | | | | | | | | | Every callsite was passing an empty SymbolContext, so this parameter had no effect. Inside the DWARF implementation of this function, however, there was one codepath that checked members of the SymbolContext. Since no call-sites actually ever used this functionality, it was essentially dead code, so I've deleted this code path as well. llvm-svn: 351132
* [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.Zachary Turner2019-01-141-3/+2
| | | | | | | | | | | | | This method took a SymbolContext but only actually cared about the case where the m_function member was set. Furthermore, it was intended to be implemented to parse blocks recursively despite not documenting this in its name. So we change the name to indicate that it should be recursive, while also limiting the function parameter to be a Function&. This lets the caller know what is required to use it, as well as letting new implementers know what kind of inputs they need to be prepared to handle. llvm-svn: 351131
* [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.Zachary Turner2019-01-111-26/+16
| | | | | | | | | | | | | | | | Previously all of these functions accepted a SymbolContext&. While a CompileUnit is one member of a SymbolContext, there are also many others, and by passing such a monolithic parameter in this way it makes the requirements and assumptions of the API unclear for both callers as well as implementors. All these methods need is a CompileUnit. By limiting the parameter type in this way, we simplify the code as well as make it self-documenting for both implementers and users. Differential Revision: https://reviews.llvm.org/D56564 llvm-svn: 350943
* Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.Zachary Turner2019-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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-101-5/+110
| | | | | | | | | | | | | | | | | | | | 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
* [NativePDB] Implement ParseDeclsForContext.Zachary Turner2019-01-021-2/+10
| | | | | | | | | | | 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-021-1/+18
| | | | | | | | | | | | | | | | | | | 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
* [NativePDB] Create VarDecls for global variables.Zachary Turner2018-12-201-0/+2
| | | | | | | | | | 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] Decouple AST reconstruction from lldb Symbol creation.Zachary Turner2018-12-171-727/+93
| | | | | | | | | | | | 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
* Remove unused variable.Richard Trieu2018-12-141-1/+0
| | | | llvm-svn: 349128
* [NativePDB] Add support for local variables.Zachary Turner2018-12-131-62/+375
| | | | | | | | | 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
* [ast] CreateParameterDeclaration should use an appropriate DeclContext.Zachary Turner2018-12-121-2/+2
| | | | | | | | | | | | | | | | | | 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-071-5/+132
| | | | | | | | | | | | 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-061-245/+3
| | | | llvm-svn: 348505
* [SymbolFile] Remove unused function. NFCI.Davide Italiano2018-11-161-18/+0
| | | | llvm-svn: 347084
* Don't use uniform initialization syntax.Zachary Turner2018-11-161-10/+9
| | | | llvm-svn: 347020
* [NativePDB] Rewrite the PdbSymUid to use our own custom namespacing scheme.Zachary Turner2018-11-161-174/+140
| | | | | | | | | | | | | | | | | | | | | | | 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
* [NativePDB] Add support for S_CONSTANT records.Zachary Turner2018-11-131-8/+132
| | | | | | | | | | | | | | | | | 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
* [NativePDB] Fix completion of enum types.Zachary Turner2018-11-091-0/+1
| | | | | | | | | | | | | This was originally submitted in a patch which fixed two unrelated bugs at the same time. This portion of the fix was reverted because it broke several other things. However, the fix employed originally was totally wrong, and attempted to change something in the ValueObject printer when actually the bug was in the NativePDB plugin. We need to mark forward enum decls as having external storage, otherwise we won't be asked to complete them when the time comes. This patch implements the proper fix, and updates tests accordingly. llvm-svn: 346517
OpenPOWER on IntegriCloud