summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/NativePDB
Commit message (Collapse)AuthorAgeFilesLines
...
* PDBFPO: Refactor register reference resolutionPavel Labath2019-04-021-60/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This refactors moves the register name->number resolution out of the FPOProgramNodeRegisterRef class. Instead I create a special FPOProgramNodeSymbol class, which holds unresolved symbols, and move the resolution into the ResolveRegisterRefs visitor. The background here is that I'd like to use this code for Breakpad unwind info, which uses similar syntax to describe unwind info. For example, a simple breakpad unwind program might look like: .cfa: $esp 8 + $ebp: .cfa 8 - ^ To be able to do this, I need to be able to customize register resolving, as that is presently hardcoded to use codeview register names, but breakpad supports a lot more architectures with different register names. Moving the resolution into a separate class will allow each user to use a different resolution logic. Reviewers: aleksandr.urakov, zturner, amccarth Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D60068 llvm-svn: 357455
* Correcting some comments in PdbIndex.cpp [NFC]Adrian McCarthy2019-03-121-5/+2
| | | | | | | | | | | | ICF can cause multiple symbols to start at the same virtual address. I plan to handle this shortly, but I wanted to correct the comment for now. Deleted an obsolete comment about adjusting the offset for the magic number at the beginning of the debug info stream. This adjustment is handled at a lower level now. llvm-svn: 355943
* 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-062-8/+8
| | | | | | | | | | | | | | | | | 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-132-4/+4
| | | | | | | | | | | | 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-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NativePDB] Process virtual bases in the correct orderAleksandr Urakov2019-02-122-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes virtual bases to be added in the correct order to the bases list. It is important because `VTableContext` (`MicrosoftVTableContext` in our case) uses then the order of virtual bases in the list to restore the virtual table indexes. These indexes are used then to resolve the layout of the virtual bases. We haven't enough information about offsets of virtual bases regarding to the object (moreover, in a common case we can't rely on such information, see the example here: https://reviews.llvm.org/D53506#1272306 ), but there should be enough information to restore the layout of the virtual bases from the indexes in runtime. After D53506 this information is used whenever possible, so there should be no problems with virtual bases' fields reading. Reviewers: zturner, rnk, stella.stamenova Subscribers: abidh, teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56904 llvm-svn: 353806
* [NFC] Fix license headers after r352845Aleksandr Urakov2019-02-084-16/+12
| | | | llvm-svn: 353503
* [PDB] Fix build after r352845Aleksandr Urakov2019-02-011-1/+1
| | | | llvm-svn: 352858
* [PDB] Fix location retrieval for function local variables and arguments that areAleksandr Urakov2019-02-0111-454/+1216
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NativePDB] Add basic support of methods recostruction in ASTAleksandr Urakov2019-01-294-7/+52
| | | | | | | | | | | | | | | | | | Summary: This patch adds the basic support of methods reconstruction by native PDB plugin. It contains only most obvious changes (it processes LF_ONEMETHOD and LF_METHOD records), some things still remain unsolved: - mangled names retrieving; - support of template methods. Reviewers: zturner, labath, lemo, stella.stamenova Reviewed by: zturner Differential Revision: https://reviews.llvm.org/D56126 llvm-svn: 352464
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1914-56/+42
| | | | | | | | | | | | | | | | | 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-142-5/+4
| | | | | | | | | | | | | | 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-142-3/+2
| | | | | | | | | | | 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-142-4/+3
| | | | | | | | | | | | | 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-112-34/+24
| | | | | | | | | | | | | | | | 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-102-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* 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
* [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 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
* 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
* [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-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
* [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
* [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
* [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
* [NativePDB] Add support for bitfield records.Zachary Turner2018-11-091-4/+20
| | | | | | | | | Bitfields are represented as LF_MEMBER records whose TypeIndex points to an LF_BITFIELD record that describes the bit width, bit offset, and underlying type of the bitfield. All we need to do is resolve these when resolving record types. llvm-svn: 346511
* [lldb] Fix initialization order warnings.Jorge Gorbe Moya2018-11-081-1/+1
| | | | | | | | | | | | | | | Moved the declaration of m_kind below the declaration of cvclass, cvunion and cvenum. This order is necessary because in one of the constructors the initialization of m_kind depends on the value of cvclass. third_party/llvm/llvm/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp:50:7: error: field 'cvclass' will be initialized after field 'm_kind' [-Werror,-Wreorder] : cvclass(std::move(c)), ^ third_party/llvm/llvm/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp:51:14: error: field 'cvclass' is uninitialized when used here [-Werror,-Wuninitialized] m_kind(cvclass.Kind == TypeRecordKind::Struct ? Struct : Class) {} llvm-svn: 346435
* [NativePDB] Higher fidelity reconstruction of AST from Debug Info.Zachary Turner2018-11-084-18/+221
| | | | | | | | | | | | | | | | | | | | | | | | | In order to accurately put a type into the correct location in the AST we construct from debug info, we need to be able to determine what DeclContext (namespace, global, nested class, etc) that it goes into. PDB doesn't contain this mapping. It does, however, contain the reverse mapping. That is, for a given class type T, you can determine all classes Q1, Q2, ..., Qn that are nested inside of T. We need to know, for a given class type Q, what type T is it nested inside of. This patch builds this map as a pre-processing step when we first load the PDB by scanning every type. Initial tests show that while this can be slow in debug builds of LLDB, it is quite fast in release builds (less than 2 seconds for a ~1GB PDB, and it only needs to happen once). Furthermore, having this pre-processing step in place allows us to repurpose it for building up other kinds of indexing to it down the line. For the time being, this gives us very accurate reconstruction of the DeclContext hierarchy. Differential Revision: https://reviews.llvm.org/D54216 llvm-svn: 346429
* Refactor ClangASTContext::AddEnumerationValueToEnumerationType() to remove ↵Shafik Yaghmour2018-11-081-6/+2
| | | | | | | | | | redundant parameter which can be calculated from other parameter. rdar://problem/43822994 Differential Revision: https://reviews.llvm.org/D54003 llvm-svn: 346428
* Fix (and improve) the support for C99 variable length array typesAdrian Prantl2018-11-052-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-052-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
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-2/+2
| | | | | | | | | 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
* [NativePDB] Get LLDB types from PDB function types.Zachary Turner2018-11-013-8/+106
| | | | | | | | | | | | | | This adds basic support for getting function signature types into LLDB's type system, including into clang's AST. There are a few edge cases which are not correctly handled, mostly dealing with nested classes, but this isn't specific to functions and apply equally to variable types. Note that no attempt has been made yet to deal with member function types, which will happen in subsequent patches. Differential Revision: https://reviews.llvm.org/D53951 llvm-svn: 345848
* [NativePDB] Add support for dumping global variables of class type.Zachary Turner2018-10-304-3/+56
| | | | | | | | | | | | | | | | | | | | | | | | | Previous patches added support for dumping global variables of primitive types, so we now do the same for class types. For the most part, everything just worked, there was only one minor bug needing fixed, which was that for variables of modified types (e.g. const, volatile, etc) we can't resolve the forward decl in CreateAndCacheType because the PdbSymUid must point to the LF_MODIFIER which must point to the forward decl. So when it comes time to call CompleteType, an assert was firing because we expected to get a class, struct, union, or enum, but we were getting an LF_MODIFIER instead. The other issue is that one the newly added tests is for an array member, which was not yet supported, so we add support for that now in this patch. There's probably room for other interesting layout test cases here, but this at least should test the basics. Differential Revision: https://reviews.llvm.org/D53822 llvm-svn: 345629
OpenPOWER on IntegriCloud