summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/CodeView
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Simplify the DenseSet used for hashing CodeView records.Zachary Turner2017-11-301-96/+44
| | | | | | | | | | | | | | This was storing the hash alongside the key so that the hash doesn't need to be re-computed every time, but in doing so it was allocating a structure to keep the key size small in the DenseMap. This is a noble goal, but it also leads to a pointer indirection on every probe, and this cost of this pointer indirection ends up being higher than the cost of having a slightly larger entry in the hash table. Removing this not only simplifies the code, but yields a small but noticeable performance improvement in the type merging algorithm. llvm-svn: 319493
* Split TypeTableBuilder into two classes.Zachary Turner2017-11-304-48/+143
| | | | llvm-svn: 319456
* [CodeView] Factor some code out of TypeTableBuilder.Zachary Turner2017-11-292-38/+36
| | | | | | | | | | | This class had some code that would automatically remap type indices before hashing and serializing. The only caller of this method was the TypeStreamMerger anyway, and the method doesn't make general sense, and prevents making certain future improvements to the class. So, factoring this up one level into the TypeStreamMerger where it belongs. llvm-svn: 319377
* Make TypeTableBuilder inherit from TypeCollection.Zachary Turner2017-11-291-0/+37
| | | | | | | | | | | | | | A couple of places in LLD were passing references to TypeTableCollections around, which makes it hard to change the implementation at runtime. However, these cases only needed to iterate over the types in the collection, and TypeCollection already provides a handy abstract interface for this purpose. By implementing this interface, we can get rid of the need to pass TypeTableBuilder references around, which should allow us to swap the implementation at runtime in subsequent patches. llvm-svn: 319345
* Fix a warning.Zachary Turner2017-11-291-1/+1
| | | | llvm-svn: 319263
* [NFC] Minor cleanups in CodeView TypeTableBuilder.Zachary Turner2017-11-281-10/+7
| | | | llvm-svn: 319260
* Fix non assert build warnings.Rafael Espindola2017-11-281-0/+3
| | | | llvm-svn: 319200
* [CodeView] Refactor / Rewrite TypeSerializer and TypeTableBuilder.Zachary Turner2017-11-288-393/+530
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation behind this patch is that future directions require us to be able to compute the hash value of records independently of actually using them for de-duplication. The current structure of TypeSerializer / TypeTableBuilder being a single entry point that takes an unserialized type record, and then hashes and de-duplicates it is not flexible enough to allow this. At the same time, the existing TypeSerializer is already extremely complex for this very reason -- it tries to be too many things. In addition to serializing, hashing, and de-duplicating, ti also supports splitting up field list records and adding continuations. All of this functionality crammed into this one class makes it very complicated to work with and hard to maintain. To solve all of these problems, I've re-written everything from scratch and split the functionality into separate pieces that can easily be reused. The end result is that one class TypeSerializer is turned into 3 new classes SimpleTypeSerializer, ContinuationRecordBuilder, and TypeTableBuilder, each of which in isolation is simple and straightforward. A quick summary of these new classes and their responsibilities are: - SimpleTypeSerializer : Turns a non-FieldList leaf type into a series of bytes. Does not do any hashing. Every time you call it, it will re-serialize and return bytes again. The same instance can be re-used over and over to avoid re-allocations, and in exchange for this optimization the bytes returned by the serializer only live until the caller attempts to serialize a new record. - ContinuationRecordBuilder : Turns a FieldList-like record into a series of fragments. Does not do any hashing. Like SimpleTypeSerializer, returns references to privately owned bytes, so the storage is invalidated as soon as the caller tries to re-use the instance. Works equally well for LF_FIELDLIST as it does for LF_METHODLIST, solving a long-standing theoretical limitation of the previous implementation. - TypeTableBuilder : Accepts sequences of bytes that the user has already serialized, and inserts them by de-duplicating with a hash table. For the sake of convenience and efficiency, this class internally stores a SimpleTypeSerializer so that it can accept unserialized records. The same is not true of ContinuationRecordBuilder. The user is required to create their own instance of ContinuationRecordBuilder. Differential Revision: https://reviews.llvm.org/D40518 llvm-svn: 319198
* [codeview] Fix handling of S_HEAPALLOCSITEReid Kleckner2017-10-241-2/+1
| | | | | | | | | | The type index is from the TPI stream, not the IPI stream. Fix the dumper, fix type index discovery, and add a test in LLD. Also improve the log message we emit when we fail to rewrite type indices in LLD. That's how I found this bug. llvm-svn: 316461
* [codeview] Add support for inlinee listsReid Kleckner2017-10-231-0/+1
| | | | | | | | | | | This adds type index discovery and dumper support for symbol record kind 0x1168, which is a list of inlined function ids. This symbol kind is undocumented, but S_INLINEES is consistent with the existing nomenclature. Fixes PR34222 llvm-svn: 316398
* [codeview] Recognize two records with no type index fieldsReid Kleckner2017-10-231-0/+2
| | | | | | | | Thunk records do not have types and frame cookies do not have types. These were found while linking libconcrt.lib from MSVC. llvm-svn: 316385
* CodeView: Provide a .def file with the register idsHans Wennborg2017-10-031-49/+3
| | | | | | | | | | | | | | The list of register ids was previously written out in a couple of dirrent places. This puts it in a .def file and also adds a few more registers (e.g. the x87 regs) which should lead to more readable dumps, but I didn't include the whole list since that seems unnecessary. X86_MC::initLLVMToSEHAndCVRegMapping is pretty ugly, but at least it's not relying on magic constants anymore. The TODO of using tablegen still stands. Differential revision: https://reviews.llvm.org/D38480 llvm-svn: 314821
* CodeView symbol dumper: use symbolic names for registersHans Wennborg2017-10-021-4/+7
| | | | | | https://reviews.llvm.org/D38469 llvm-svn: 314690
* [llvm-pdbutil] Support dumping CodeView from object files.Zachary Turner2017-09-012-3/+38
| | | | | | | | | | | | | | | | | | | | | | | | We have llvm-readobj for dumping CodeView from object files, and llvm-pdbutil has always been more focused on PDB. However, llvm-pdbutil has a lot of useful options for summarizing debug information in aggregate and presenting high level statistical views. Furthermore, it's arguably better as a testing tool since we don't have to write tests to conform to a state-machine like structure where you match multiple lines in succession, each depending on a previous match. llvm-pdbutil dumps much more concisely, so it's possible to use single-line matches in many cases where as with readobj tests you have to use multi-line matches with an implicit state machine. Because of this, I'm adding object file support to llvm-pdbutil. In fact, this mirrors the cvdump tool from Microsoft, which also supports both object files and pdb files. In the future we could perhaps rename this tool llvm-cvutil. In the meantime, this allows us to deep dive into object files the same way we already can with PDB files. llvm-svn: 312358
* [PDB] Serialize records into a stack-allocated buffer.Zachary Turner2017-08-211-2/+1
| | | | | | | | | | | | We were using a std::vector<> and resizing to MaxRecordLength, which is ~64KB. We would then do this repeatedly often many times in a tight loop, which was causing measurable performance impact when linking PDBs. Patch by Alex Telishev Differential Revision: https://reviews.llvm.org/D36940 llvm-svn: 311375
* Remove unused variable.Zachary Turner2017-08-171-1/+0
| | | | llvm-svn: 311119
* [llvm-pdbutil] Fix some dumping issues.Zachary Turner2017-08-171-1/+3
| | | | | | | | | | | | | | | | | When dumping, we were treating the S_INLINESITESYM as referring to a type record, when it actually refers to an id record. We had this correct in TypeIndexDiscovery, so our merging algorithm should be fine, but we had it wrong in the dumper, which means it would appear to work most of the time, unless the index was out of bounds in the type stream, when it would fail. Fixed this, and audited a few other cases to make them match the behavior in TypeIndexDiscovery. Also, I've now observed a new symbol record with kind 0x1168 which I have no clue what it is, so to avoid crashing we have to just print "Unknown Symbol Kind". llvm-svn: 311117
* [LLD/PDB] Write actual records to the globals stream.Zachary Turner2017-08-114-5/+82
| | | | | | | | | | | | | | | | Previously we were writing an empty globals stream. Windows tools interpret this as "private symbols are not present in this PDB", even when they are, so we need to fix this. Regardless, without it we don't have information about global variables, so we need to fix it anyway. This patch does that. With this patch, the "lm" command in WinDbg correctly reports that we have private symbols available, but the "dv" command still refuses to display local variables. Differential Revision: https://reviews.llvm.org/D36535 llvm-svn: 310743
* [PDB] Fix linking of function symbols and local variables.Zachary Turner2017-08-081-8/+39
| | | | | | | | | | | | | | | | | | | | | | | | The compiler outputs PROC32_ID symbols into the object files for functions, and these symbols have an embedded type index which, when copied to the PDB, refer to the IPI stream. However, the symbols themselves are also converted into regular symbols (e.g. S_GPROC32_ID -> S_GPROC32), and type indices in the regular symbol records refer to the TPI stream. So this patch applies two fixes to function records. 1. It converts ID symbols to the proper non-ID record type. 2. After remapping the type index from the object file's index space to the PDB file/IPI stream's index space, it then remaps that index to the TPI stream's index space by. Besides functions, during the remapping process we were also discarding symbol record types which we did not recognize. In particular, we were discarding S_BPREL32 records, which is what MSVC uses to describe local variables on the stack. So this patch fixes that as well by copying them to the PDB. Differential Revision: https://reviews.llvm.org/D36426 llvm-svn: 310394
* [PDB] Improve GSI hash table dumping for publics and globalsReid Kleckner2017-07-261-0/+6
| | | | | | | | | | | | | | | The PDB "symbol stream" actually contains symbol records for the publics and the globals stream. The globals and publics streams are essentially hash tables that point into a single stream of records. In order to match cvdump's behavior, we need to only dump symbol records referenced from the hash table. This patch implements that, and then implements global stream dumping, since it's just a subset of public stream dumping. Now we shouldn't see S_PROCREF or S_GDATA32 records when dumping publics, and instead we should see those record in the globals stream. llvm-svn: 309066
* [codeview] Emit 'D' as the cv source language for D codeReid Kleckner2017-07-241-1/+1
| | | | | | | | | This matches DMD: https://github.com/dlang/dmd/blob/522263965cf3a27ed16b31f3c3562db86cdeabec/src/ddmd/backend/cv8.c#L199 Fixes PR33899. llvm-svn: 308890
OpenPOWER on IntegriCloud