summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFC] Make CompilerDeclContext construction type safeRaphael Isemann2019-12-231-4/+3
| | | | | | | | | | | | | | | The CompilerDeclContext constructor takes a void* pointer which means that all callers of this constructor need to first explicitly convert all pointers to clang::DeclContext*. This causes that we for example can't just pass a TranslationUnitDecl* to the constructor without first casting it to its parent class (as it inherits from both Decl and DeclContext so the void* pointer is actually a Decl*). This patch introduces a utility function in the ClangASTContext which gets rid of the requirement to cast all pointers to clang::DeclContext. Also moves all constructor calls to use this function instead which is NFC (beside the change in DWARFASTParserClangTests.cpp).
* [lldb] Don't put compile unit name into the support file list and support ↵Pavel Labath2019-12-051-7/+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
* [lldb] Remove FileSpec->CompileUnit inheritancePavel Labath2019-11-291-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: CompileUnit is a complicated class. Having it be implicitly convertible to a FileSpec makes reasoning about it even harder. This patch replaces the inheritance by a simple member and an accessor function. This avoid the need for casting in places where one needed to force a CompileUnit to be treated as a FileSpec, and does not add much verbosity elsewhere. It also fixes a bug where we were wrongly comparing CompileUnit& and a CompileUnit*, which compiled due to a combination of this inheritance and the FileSpec*->FileSpec implicit constructor. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70827
* 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-3/+4
| | | | | | | | | | | | | | 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
* (NFC) Delete variable made unused by llvm-svn: 375160Sterling Augustine2019-10-171-1/+0
| | | | | | | | | | | | Reviewers: aprantl Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69143 llvm-svn: 375174
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-171-36/+20
| | | | | | | | | | | | 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
* Remove the is_mangled flag from Mangled and SymbolAdrian Prantl2019-10-091-1/+0
| | | | | | | | | | | | | | | Testing whether a name is mangled or not is extremely cheap and can be done by looking at the first two characters. Mangled knows how to do it. On the flip side, many call sites that currently pass in an is_mangled determination do not know how to correctly do it (for example, they leave out Swift mangling prefixes). This patch removes this entry point and just forced Mangled to determine the mangledness of a string itself. Differential Revision: https://reviews.llvm.org/D68674 llvm-svn: 374180
* [lldb] Fix unused variable warningJordan Rupprecht2019-10-011-1/+0
| | | | llvm-svn: 373399
* Update SymbolFilePDB for FindTypes API change.Adrian Prantl2019-10-011-15/+10
| | | | | | This is untested, I don't have access to a Windows machine. llvm-svn: 373342
* Remove unused "append" parameter from FindTypes APIAdrian Prantl2019-09-301-6/+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-1/+1
| | | | | | | | | | 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
* SymbolVendor: Remove the object file member variablePavel Labath2019-07-311-13/+14
| | | | | | | | | | | | | | | | | | Summary: The last responsibility of the SymbolVendor was to hold an owning reference to the object file (in case symbols are being read from a different file than the main module). As SymbolFile classes already hold a non-owning reference to the object file, we can easily remove this responsibility of the SymbolVendor by making the SymbolFile reference owning. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65401 llvm-svn: 367392
* Change '|' to '&' in conditional.Richard Trieu2019-07-311-1/+1
| | | | | | | | Bitwise-or with a non-zero constant will always evaluate to true. Switch to bitwise-and which will only evalute to true if the specified bit is set in the other operand. llvm-svn: 367386
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-301-31/+117
| | | | | | | | | | | | | | | | | | 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/+17
| | | | | | | | | | | | | | | | | | | | | | 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-7/+1
| | | | | | | | | | | | | | | | | | | | | 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-30/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Kill unused variable m_tu_decl_up in SymbolFilePDBNathan Lanza2019-03-271-9/+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
* 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
* 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
* ObjectFilePECOFF: Create a "container" section spanning the entire module imagePavel Labath2019-02-131-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is coming from the discussion in D55356 (the most interesting part happened on the mailing list, so it isn't reflected on the review page). In short the issue is that lldb assumes that all bytes of a module image in memory will be backed by a "section". This isn't the case for PECOFF files because the initial bytes of the module image will contain the file header, which does not correspond to any normal section in the file. In particular, this means it is not possible to implement GetBaseAddress function for PECOFF files, because that's supposed point to the first byte of that header. If my (limited) understanding of how PECOFF files work is correct, then the OS is expecded to load the entire module into one continuous chunk of memory. The address of that chunk (+/- ASLR) is given by the "image base" field in the COFF header, and it's size by "image size". All of the COFF sections are then loaded into this range. If that's true, then we can model this behavior in lldb by creating a "container" section to represent the entire module image, and then place other sections inside that. This would make be consistent with how MachO and ELF files are modelled (except that those can have multiple top-level containers as they can be loaded into multiple discontinuous chunks of memory). This change required a small number of fixups in the PDB plugins, which assumed a certain order of sections within the object file (which obivously changes now). I fix this by changing the lookup code to use section IDs (which are unchanged) instead of indexes. This has the nice benefit of removing spurious -1s in the plugins as the section IDs in the pdbs match the 1-based section IDs in the COFF plugin. Besides making the implementation of GetBaseAddress possible, this also improves the lookup of addresses in the gaps between the object file sections, which will now be correctly resolved as belonging to the object file. Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo Reviewed By: clayborg, lemo Subscribers: JDevlieghere, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56537 llvm-svn: 353916
* [PDB] Fix location retrieval for function local variables and arguments that areAleksandr Urakov2019-02-011-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+0
| | | | | | | | | | | | | | 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-1/+0
| | | | | | | | | | | 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-12/+8
| | | | | | | | | | | | | 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-50/+35
| | | | | | | | | | | | | | | | 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-22/+11
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Change lldb-test to use ParseAllDebugSymbols.Zachary Turner2019-01-091-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* NFC: fix compiler warning about code never being executed when compiling on ↵Greg Clayton2018-12-121-3/+4
| | | | | | non windows platform. llvm-svn: 348951
* [PDB] Support PDB-backed expressions evaluation (+ fix stuck test)Aleksandr Urakov2018-12-031-19/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-301-25/+19
| | | | | | | | | 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-301-19/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-301-0/+52
| | | | | | | | | | | | | | | | | | | | | | 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
* Remove comments after header includes.Jonas Devlieghere2018-11-111-1/+1
| | | | | | | | | | This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
* [PDB] Introduce `MSVCUndecoratedNameParser`Aleksandr Urakov2018-11-061-26/+16
| | | | | | | | | | | | This patch introduces the simple MSVCUndecoratedNameParser. It is needed for parsing names of PDB symbols corresponding to template instantiations. For example, for the name `operator<<A>'::`2'::B::operator> we can't just split the name with :: (as it is implemented for now) to retrieve its scopes. This parser processes such names in a more correct way. Differential Revision: https://reviews.llvm.org/D52461 llvm-svn: 346213
* Fix (and improve) the support for C99 variable length array typesAdrian Prantl2018-11-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this: 0x00000051: DW_TAG_variable [4] DW_AT_location( fbreg -32 ) DW_AT_name( "__vla_expr" ) DW_AT_type( {0x000000d3} ( long unsigned int ) ) DW_AT_artificial( true ) ... 0x000000da: DW_TAG_array_type [10] * DW_AT_type( {0x000000cc} ( int ) ) 0x000000df: DW_TAG_subrange_type [11] DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) ) DW_AT_count( {0x00000051} ) Without this patch LLDB will naively interpret the DIE offset 0x51 as the static size of the array, which is clearly wrong. This patch extends ValueObject::GetNumChildren to query the dynamic properties of incomplete array types. See the testcase for an example: 4 int foo(int a) { 5 int vla[a]; 6 for (int i = 0; i < a; ++i) 7 vla[i] = i; 8 -> 9 pause(); // break here 10 return vla[a-1]; 11 } (lldb) fr v vla (int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3) (lldb) quit rdar://problem/21814005 Differential Revision: https://reviews.llvm.org/D53530 llvm-svn: 346165
* Add a target modules dump ast command.Zachary Turner2018-11-051-0/+8
| | | | | | | | | | This is useful for investigating the clang ast as you reconstruct it via by parsing debug info. It can also be used to write tests against. Differential Revision: https://reviews.llvm.org/D54072 llvm-svn: 346149
* Revert "[Symbol] Search symbols with name and type in a symbol file"Davide Italiano2018-11-021-49/+0
| | | | | | It broke MacOS buildbots. llvm-svn: 346045
* [Symbol] Search symbols with name and type in a symbol fileAleksandr Urakov2018-11-021-0/+49
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file. 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: emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53368 llvm-svn: 345957
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-3/+3
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner2018-10-251-2/+2
| | | | | | | | | | This is similar to D53597, but following up with 2 more enums. After this, all flag enums should be strongly typed all the way through to the symbol files plugins. Differential Revision: https://reviews.llvm.org/D53616 llvm-svn: 345314
OpenPOWER on IntegriCloud