summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/CodeView
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1939-156/+117
| | | | | | | | | | | | | | | | | 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
* [CodeView] More appropriate name and type for a Microsoft precompiled ↵Alexandre Ganea2019-01-071-21/+21
| | | | | | headers parameter. NFC llvm-svn: 350520
* [PDB] Add some helper functions for working with scopes.Zachary Turner2018-12-171-2/+32
| | | | llvm-svn: 349361
* [NativePDB] Reconstruct function declarations from debug info.Zachary Turner2018-12-071-1/+12
| | | | | | | | | | | | 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-062-1/+55
| | | | llvm-svn: 348505
* Support skewed stream arrays.Zachary Turner2018-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeView] Add support for ref-qualified member functions.Zachary Turner2018-11-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | When you have a member function with a ref-qualifier, for example: struct Foo { void Func() &; void Func2() &&; }; clang-cl was not emitting this information. Doing so is a bit awkward, because it's not a property of the LF_MFUNCTION type, which is what you'd expect. Instead, it's a property of the this pointer which is actually an LF_POINTER. This record has an attributes bitmask on it, and our handling of this bitmask was all wrong. We had some parts of the bitmask defined incorrectly, but importantly for this bug, we didn't know about these extra 2 bits that represent the ref qualifier at all. Differential Revision: https://reviews.llvm.org/D54667 llvm-svn: 347354
* [CodeView] Don't print PointerAttributes when dumping.Zachary Turner2018-11-201-1/+0
| | | | | | | | PointerAttributes is a bitwise-or of several other fields, each of which is already printed on its own line with a better explanation. So this doesn't really help much. llvm-svn: 347275
* [NativePDB] Improved support for nested type reconstruction.Zachary Turner2018-11-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [COFF][LLD] Add link support for Microsoft precompiled headers OBJsAlexandre Ganea2018-11-052-35/+82
| | | | | | | | | | | This change allows for link-time merging of debugging information from Microsoft precompiled types OBJs compiled with cl.exe /Z7 /Yc and /Yu. This fixes llvm.org/PR34278 Differential Revision: https://reviews.llvm.org/D45213 llvm-svn: 346154
* [codeview] Add breaks to fix -Wimplicit-fallthroughReid Kleckner2018-11-011-0/+2
| | | | | | | | | This is a minor bug fix. Previously, if you tried to encode the RSP register on the x86 platform, that might have succeeded and been encoded incorrectly. However, no existing producer or consumer passes the x86_64 registers when targeting x86_32. llvm-svn: 345879
* [CodeView] Emit the correct TypeIndex for std::nullptr_t.Zachary Turner2018-11-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | The TypeIndex used by cl.exe is 0x103, which indicates a SimpleTypeMode of NearPointer (note the absence of the bitness, normally pointers use a mode of NearPointer32 or NearPointer64) and a SimpleTypeKind of void. So this is basically a void*, but without a specified size, which makes sense given how std::nullptr_t is defined. clang-cl was actually not emitting *anything* for this. Instead, when we encountered std::nullptr_t in a DIType, we would actually just emit a TypeIndex of 0, which is obviously wrong. std::nullptr_t in DWARF is represented as a DW_TAG_unspecified_type with a name of "decltype(nullptr)", so we add that logic along with a test, as well as an update to the dumping code so that we no longer print void* when dumping 0x103 (which would previously treat Void/NearPointer no differently than Void/NearPointer64). Differential Revision: https://reviews.llvm.org/D53957 llvm-svn: 345811
* Fix a compilation failure on non-MSVC compilers.Zachary Turner2018-10-081-1/+1
| | | | llvm-svn: 343952
* [PDB] Add the ability to lookup global symbols by name.Zachary Turner2018-10-081-1/+2
| | | | | | | | | | The Globals table is a hash table keyed on symbol name, so it's possible to lookup symbols by name in O(1) time. Add a function to the globals stream to do this, and add an option to llvm-pdbutil to exercise this, then use it to write some tests to verify correctness. llvm-svn: 343951
* [codeview] Emit S_FRAMEPROC and use S_DEFRANGE_FRAMEPOINTER_RELReid Kleckner2018-10-011-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, LLVM would always describe locals on the stack as being relative to some specific register, RSP, ESP, EBP, ESI, etc. Variables in stack memory are pretty common, so there is a special S_DEFRANGE_FRAMEPOINTER_REL symbol for them. This change uses it to reduce the size of our debug info. On top of the size savings, there are cases on 32-bit x86 where local variables are addressed from ESP, but ESP changes across the function. Unlike in DWARF, there is no FPO data to describe the stack adjustments made to push arguments onto the stack and pop them off after the call, which makes it hard for the debugger to find the local variables in frames further up the stack. To handle this, CodeView has a special VFRAME register, which corresponds to the $T0 variable set by our FPO data in 32-bit. Offsets to local variables are instead relative to this value. This is part of PR38857. Reviewers: hans, zturner, javed.absar Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D52217 llvm-svn: 343543
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-272-2/+2
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [PDB] Add native reading support for UDT / class types.Zachary Turner2018-09-212-0/+54
| | | | | | | | | | | | This allows the native reader to find records of class/struct/ union type and dump them. This behavior is tested by using the diadump subcommand against golden output produced by actual DIA SDK on the same PDB file, and again using pretty -native to confirm that we actually dump the classes. We don't find class members or anything like that yet, for now it's just the class itself. llvm-svn: 342779
* [PDB] Write FPO Data to the PDB.Zachary Turner2018-09-111-7/+25
| | | | llvm-svn: 342003
* [codeview] Decode and dump FP regs from S_FRAMEPROC recordsReid Kleckner2018-09-112-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are two registers encoded in the S_FRAMEPROC flags: one for locals and one for parameters. The encoding is described by the ExpandEncodedBasePointerReg function in cvinfo.h. Two bits are used to indicate one of four possible values: 0: no register - Used when there are no variables. 1: SP / standard - Variables are stored relative to the standard SP for the ISA. 2: FP - Variables are addressed relative to the ISA frame pointer, i.e. EBP on x86. If realignment is required, parameters use this. If a dynamic alloca is used, locals will be EBP relative. 3: Alternative - Variables are stored relative to some alternative third callee-saved register. This is required to address highly aligned locals when there are dynamic stack adjustments. In this case, both the incoming SP saved in the standard FP and the current SP are at some dynamic offset from the locals. LLVM uses ESI in this case, MSVC uses EBX. Most of the changes in this patch are to pass around the CPU so that we can decode these into real, named architectural registers. Subscribers: hiraditya Differential Revision: https://reviews.llvm.org/D51894 llvm-svn: 341999
* [DebugInfo] Common behavior for error typesAlexandre Ganea2018-08-312-31/+6
| | | | | | | | | | | | | | | Following D50807, and heading towards D50664, this intermediary change does the following: 1. Upgrade all custom Error types in llvm/trunk/lib/DebugInfo/ to use the new StringError behavior (D50807). 2. Implement std::is_error_code_enum and make_error_code() for DebugInfo error enumerations. 3. Rename GenericError -> PDBError (the file will be renamed in a subsequent commit) 4. Update custom error messages to follow the same formatting: (\w\s*)+\. 5. Keep generic "file not found" (ENOENT) errors as they are in PDB code. Previously, there used to be a custom enumeration for that purpose. 6. Remove a few extraneous LF in log() implementations. Printing LF is a responsability at a higher level, not at the error level. Differential Revision: https://reviews.llvm.org/D51499 llvm-svn: 341228
* [CodeView] Minimal support for S_UNAMESPACE recordsAlexandre Ganea2018-07-314-1/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D50007 llvm-svn: 338417
* This fixes a crash when a second pass is required for the Codeview Type ↵Alexandre Ganea2018-07-301-1/+4
| | | | | | | | | | merging *and* the index points outside of the table (which should lead to an error being printed). This occurs currently until MS precompiled headers .obj is added (see D45213) Differential Revision: https://reviews.llvm.org/D50006 llvm-svn: 338308
* [CodeView] Correctly compute the name of S_PROCREF symbols.Zachary Turner2018-06-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a function which switches on the type of a symbol record to return a hardcoded offset into the record that contains the symbol name. Not all symbols have names to begin with, and for those records we return -1 for the offset. Names are used for various things. Importantly for this particular bug, a hash of the record name is used as a key for certain hash tables which are serialied into the PDB file. One of these hash tables is for the global symbol stream, which is basically a collection of S_PROCREF symbols which contain the name of the symbol, a module, and an address offset. However, for S_PROCREF symbols, the function to return the offset of the name was returning -1: basically it wasn't implemented. As a result of this, all global symbols were hashing to the same value, essentially it was as if every single global symbol's name was the empty string. This manifests in the VS debugger when you try to call a function (global or member, doesn't matter) through the immediate window and the debugger simply reports an error because it can't find the function. This makes perfect sense, because it is hashing the name for real, looking in the global symbol hash table, and there is only 1 entry there which corresponds to a symbol whose name is the empty string. Fixing this fixes the MSVC debugger in this case. llvm-svn: 336024
* Resubmit [pdb] Change /DEBUG:GHASH to emit 8 byte hashes."Zachary Turner2018-05-171-5/+5
| | | | | | | This fixes the remaining failing tests, so resubmitting with no functional change. llvm-svn: 332676
* Revert "[pdb] Change /DEBUG:GHASH to emit 8 byte hashes."Zachary Turner2018-05-171-4/+5
| | | | | | | A few tests haven't been properly updated, so reverting while I have time to investigate proper fixes. llvm-svn: 332672
* [pdb] Change /DEBUG:GHASH to emit 8 byte hashes.Zachary Turner2018-05-171-5/+4
| | | | | | | | | | | | | | | | Previously we emitted 20-byte SHA1 hashes. This is overkill for identifying debug info records, and has the negative side effect of making object files bigger and links slower. By using only the last 8 bytes of a SHA1, we get smaller object files and ~10% faster links. This modifies the format of the .debug$H section by adding a new value for the hash algorithm field, so that the linker will still work when its object files have an old format. Differential Revision: https://reviews.llvm.org/D46855 llvm-svn: 332669
* [codeview] Include record prefix in global type hashingReid Kleckner2018-05-171-0/+1
| | | | | | | | | | | | The prefix includes type kind, which is important to preserve. Two different type leafs can easily have the same interior record contents as another type. We ran into this issue in PR37492 where a bitfield type record collided with a const modifier record. Their contents were bitwise identical, but their kinds were different. llvm-svn: 332664
* [CodeView] Initial support for emitting S_THUNK32 symbols for compiler...Brock Wyma2018-04-161-0/+1
| | | | | | | | | | | When emitting CodeView debug information, compiler-generated thunk routines should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so Visual Studio can properly step into the user code. This initial support only handles standard thunk ordinals. Differential Revision: https://reviews.llvm.org/D43838 llvm-svn: 330132
* [DebugInfo] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-131-1/+1
| | | | | | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. llvm-svn: 330061
* [DebugInfo][COFF] Fix reading variable-length encoded recordsAlexandre Ganea2018-04-101-2/+2
| | | | | | | | | | | | While reading Codeview records which contain variable-length encoded integers, such as LF_BCLASS, LF_ENUMERATE, LF_MEMBER, LF_VBCLASS or LF_IVBCLASS, the record's size would be improperly calculated in cases where the value was indeed of a variable length (>= LF_NUMERIC). This caused a bad alignement on the next record, which would/might crash later on. Differential Revision: https://reviews.llvm.org/D45104 llvm-svn: 329659
* Fix line endings (CR/LF -> LF) introduced by rL329613Alexandre Ganea2018-04-103-1400/+1400
| | | | | reviewer: zturner llvm-svn: 329646
* [Debuginfo][COFF] Minimal serialization support for precompiled types recordsAlexandre Ganea2018-04-093-1360/+1400
| | | | | | | | | | | | | This change adds support for the LF_PRECOMP and LF_ENDPRECOMP records required to read/write Microsoft precompiled types .objs. See https://en.wikipedia.org/wiki/Precompiled_header#Microsoft_Visual_C_and_C++ This also adds handling for the .debug$P section, which is actually a .debug$T section in disguise, found only in precompiled .objs. Differential Revision: https://reviews.llvm.org/D45283 llvm-svn: 329613
* [DebugInfo] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: echristo, zturner, samsonov Reviewed By: echristo Subscribers: JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D45134 llvm-svn: 328935
* [PDB] Make our PDBs look more like MS PDBs.Zachary Turner2018-03-231-0/+9
| | | | | | | | | | | | | | | | | | When investigating bugs in PDB generation, the first step is often to do the same link with link.exe and then compare PDBs. But comparing PDBs is hard because two completely different byte sequences can both be correct, so it hampers the investigation when you also have to spend time figuring out not just which bytes are different, but also if the difference is meaningful. This patch fixes a couple of cases related to string table emission, hash table emission, and the order in which we emit strings that makes more of our bytes the same as the bytes generated by MS PDBs. Differential Revision: https://reviews.llvm.org/D44810 llvm-svn: 328348
* [Codeview/PDB] Rename some methods for clarity.Zachary Turner2018-03-223-12/+21
| | | | | | | | | NFC, this just renames some methods to better express what they do, and also adds a few helper methods to add some symmetry to the API in a few places (for example there was a getStringFromId but not a getIdFromString method in the string table). llvm-svn: 328221
* Revert "Resubmit "Support embedding natvis files in PDBs.""Zachary Turner2018-03-203-21/+12
| | | | | | | | This is still failing on a different bot this time due to some issue related to hashing absolute paths. Reverting until I can figure it out. llvm-svn: 328014
* Resubmit "Support embedding natvis files in PDBs."Zachary Turner2018-03-203-12/+21
| | | | | | | | | | | The issue causing this to fail in certain configurations should be fixed. It was due to the fact that DIA apparently expects there to be a null string at ID 1 in the string table. I'm not sure why this is important but it seems to make a difference, so set it. llvm-svn: 328002
* Revert "Support embedding natvis files in PDBs."Zachary Turner2018-03-193-21/+12
| | | | | | | This is causing a test failure on a certain bot, so I'm removing this temporarily until we can figure out the source of the error. llvm-svn: 327903
* Support embedding natvis files in PDBs.Zachary Turner2018-03-193-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | Natvis is a debug language supported by Visual Studio for specifying custom visualizers. The /NATVIS option is an undocumented link.exe flag which will take a .natvis file and "inject" it into the PDB. This way, you can ship the debug visualizers for a program along with the PDB, which is very useful for postmortem debugging. This is implemented by adding a new "named stream" to the PDB with a special name of /src/files/<natvis file name> and simply copying the contents of the xml into this file. Additionally, we need to emit a single stream named /src/headerblock which contains a hash table of embedded files to records describing them. This patch adds this functionality, including the /NATVIS option to lld-link. Differential Revision: https://reviews.llvm.org/D44328 llvm-svn: 327895
* [CodeView] Lower __restrict and other pointer qualifiers correctlyReid Kleckner2018-02-272-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Qualifiers on a pointer or reference type may apply to either the pointee or the pointer itself. Consider 'const char *' and 'char * const'. In the first example, the pointee data may not be modified without casts, and in the second example, the pointer may not be updated to point to new data. In the general case, qualifiers are applied to types with LF_MODIFIER records, which support the usual const and volatile qualifiers as well as the __unaligned extension qualifier. However, LF_POINTER records, which are used for pointers, references, and member pointers, have flags for qualifiers applying to the *pointer*. In fact, this is the only way to represent the restrict qualifier, which can only apply to pointers, and cannot qualify regular data types. This patch causes LLVM to correctly fold 'const' and 'volatile' pointer qualifiers into the pointer record, as well as adding support for '__restrict' qualifiers in the same place. Based on a patch from Aaron Smith Differential Revision: https://reviews.llvm.org/D43060 llvm-svn: 326260
* [codeview] Remove unused variableReid Kleckner2018-02-271-1/+0
| | | | llvm-svn: 326253
* [CodeView] Micro-optimizations to speed up type merging.Zachary Turner2018-01-302-115/+91
| | | | | | | | | | | | Based on a profile, a couple of hot spots were identified in the main type merging loop. The code was simplified, a few loops were re-arranged, and some outlined functions were inlined. This speeds up type merging by a decent amount, shaving around 3-4 seconds off of a 40 second link in my test case. Differential Revision: https://reviews.llvm.org/D42559 llvm-svn: 323790
* Speed up iteration of CodeView record streams.Zachary Turner2018-01-181-4/+6
| | | | | | | | | | | | | There's some abstraction overhead in the underlying mechanisms that were being used, and it was leading to an abundance of small but not-free copies being made. This showed up on a profile. Eliminating this and going back to a low-level byte-based implementation speeds up lld with /DEBUG between 10 and 15%. Differential Revision: https://reviews.llvm.org/D42148 llvm-svn: 322871
* [COFF] Teach LLD to use the COFF .debug$H section.Zachary Turner2017-12-142-13/+116
| | | | | | | | | | | | This adds the /DEBUG:GHASH option to LLD which will look for the existence of .debug$H sections in linker inputs and use them to accelerate type merging. The clang-cl side has already been added, so this completes the work necessary to begin experimenting with this feature. Differential Revision: https://reviews.llvm.org/D40980 llvm-svn: 320719
* [CodeView] Teach clang to emit the .debug$H COFF section.Zachary Turner2017-12-132-0/+128
| | | | | | | | | | | | | | | Currently this is an LLVM extension to the COFF spec which is experimental and intended to speed up linking. For now it is behind a hidden cl::opt flag, but in the future we can move it to a "real" cc1 flag and have the driver pass it through whenever it is appropriate. The patch to actually make use of this section in lld will come in a followup. Differential Revision: https://reviews.llvm.org/D40917 llvm-svn: 320649
* Remove redundant includes from lib/DebugInfo.Michael Zolotukhin2017-12-136-7/+0
| | | | llvm-svn: 320620
* [DebugInfo] Fix register variables not showing up in pdb.Zachary Turner2017-12-071-0/+3
| | | | | | | | | | | | | Previously, when linking against libcmt from the MSVC runtime, lld-link /verbose would show "Ignoring unknown symbol record with kind 0x1006". It turns out this was because TypeIndexDiscovery did not handle S_REGISTER records, so these records were not getting properly remapped. Patch by: Alexnadre Ganea Differential Revision: https://reviews.llvm.org/D40919 llvm-svn: 320108
* Teach llvm-pdbutil to dump types from object files.Zachary Turner2017-12-051-4/+10
| | | | llvm-svn: 319859
* Fix -Wmissing-braces error.Zachary Turner2017-12-051-2/+2
| | | | llvm-svn: 319855
* [CodeView] Add support for content hashing CodeView type records.Zachary Turner2017-12-053-34/+83
| | | | | | | | | Currently nothing uses this, but this at least gets the core algorithm in, and adds some test to demonstrate correctness. Differential Revision: https://reviews.llvm.org/D40736 llvm-svn: 319854
OpenPOWER on IntegriCloud