summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-pdbutil
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix -Wtrigraphs.Rui Ueyama2018-09-201-1/+1
| | | | llvm-svn: 342674
* [PDB] Add the ability to map forward references to full decls.Zachary Turner2018-09-205-12/+59
| | | | | | | | | | | | | | | | | | | | | Some records point to an LF_CLASS, LF_UNION, LF_STRUCTURE, or LF_ENUM which is a forward reference and doesn't contain complete debug information. In these cases, we'd like to be able to quickly locate the full record. The TPI stream stores an array of pre-computed record hash values, one for each type record. If we pre-process this on startup, we can build a mapping from hash value -> {list of possible matching type indices}. Since hashes of full records are only based on the name and or unique name and not the full record contents, we can then use forward ref record to compute the hash of what *would* be the full record by just hashing the name, use this to get the list of possible matches, and iterate those looking for a match on name or unique name. llvm-pdbutil is updated to resolve forward references for the purposes of testing (plus it's just useful). Differential Revision: https://reviews.llvm.org/D52283 llvm-svn: 342656
* [PDB] Better support for enumerating pointer types.Zachary Turner2018-09-181-2/+24
| | | | | | | | | | | | | | | | | | | There were several issues with the previous implementation. 1) There were no tests. 2) We didn't support creating PDBSymbolTypePointer records for builtin types since those aren't described by LF_POINTER records. 3) We didn't support a wide enough variety of builtin types even ignoring pointers. This patch fixes all of these issues. In order to add tests, it's helpful to be able to ignore the symbol index id hierarchy because it makes the golden output from the DIA version not match our output, so I've extended the dumper to disable dumping of id fields. llvm-svn: 342493
* [PDB] Make the native reader support enumerators.Zachary Turner2018-09-171-0/+8
| | | | | | | | | | | Previously we would dump the names of enum types, but not their enumerator values. This adds support for enumerator values. In doing so, we have to introduce a general purpose mechanism for caching symbol indices of field list members. Unlike global types, FieldList members do not have a TypeIndex. So instead, we identify them by the pair {TypeIndexOfFieldList, IndexInFieldList}. llvm-svn: 342415
* Give InfoStreamBuilder an opt-in method to write a hash of the PDB as GUID.Nico Weber2018-09-151-2/+5
| | | | | | | | | | | | | Naively computing the hash after the PDB data has been generated is in practice as fast as other approaches I tried. I also tried online-computing the hash as parts of the PDB were written out (https://reviews.llvm.org/D51887; that's also where all the measuring data is) and computing the hash in parallel (https://reviews.llvm.org/D51957). This approach here is simplest, without being slower. Differential Revision: https://reviews.llvm.org/D51956 llvm-svn: 342333
* [PDB] Make the pretty dumper output modified types.Zachary Turner2018-09-143-5/+35
| | | | | | | | | | | Currently if we got something like `const Foo` we'd ignore it and just rely on printing the unmodified `Foo` later on. However, for testing the native reading code we really would like to be able to see these so that we can verify that the native reader can actually handle them. Instead of printing out the full type though, just print out the header. llvm-svn: 342295
* [PDB] Emit old fpo data to the PDB file.Zachary Turner2018-09-122-9/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | r342003 added support for emitting FPO data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the PDB file. However, that is not the end of the story. FPO can end up in two different destinations in a PDB, each corresponding to a different FPO data source. The case handled by r342003 involves copying data from the DEBUG_S_FRAMEDATA subsection of the .debug$S section to the "New FPO" stream in the PDB, which is then referred to by the DBI stream. The case handled by this patch involves copying records from the .debug$F section of an object file to the "FPO" stream (or perhaps more aptly, the "Old FPO" stream) in the PDB file, which is also referred to by the DBI stream. The formats are largely similar, and the difference is mostly only visible in masm generated object files, such as some of the low-level CRT object files like memcpy. MASM doesn't appear to support writing the DEBUG_S_FRAMEDATA subsection, and instead just writes these records to the .debug$F section. Although clang-cl does not emit a .debug$F section ever, lld still needs to support it so we have good debugging for CRT functions. Differential Revision: https://reviews.llvm.org/D51958 llvm-svn: 342080
* [PDB] Write FPO Data to the PDB.Zachary Turner2018-09-114-0/+64
| | | | llvm-svn: 342003
* Apply local fixes intended to be part of r341999.'Reid Kleckner2018-09-111-2/+2
| | | | llvm-svn: 342000
* [codeview] Decode and dump FP regs from S_FRAMEPROC recordsReid Kleckner2018-09-112-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PDB] Support pointer types in the native reader.Zachary Turner2018-09-071-0/+50
| | | | | | | | | | In order to start testing this, I've added a new mode to llvm-pdbutil which is only really useful for writing tests. It just dumps the value of raw fields in record format. This isn't really ideal and it won't allow us to test some important cases, but it's better than nothing for now. llvm-svn: 341729
* [codeview] Improve readobj FPO dumper and pdbutil register namesReid Kleckner2018-09-071-8/+17
| | | | | | The improved dumping helps me investigate PR38857. llvm-svn: 341695
* [PDB] Refactor the PDB symbol classes to fix a reuse bug.Zachary Turner2018-09-051-1/+3
| | | | | | | | | | | | | | | | | | | | The way DIA SDK works is that when you request a symbol, it gets assigned an internal identifier that is unique for the life of the session. You can then use this identifier to get back the same symbol, with all of the same internal state that it had before, even if you "destroyed" the original copy of the object you had. This didn't work properly in our native implementation, and if you destroyed an object for a particular symbol, then requested the same symbol again, it would get assigned a new ID and you'd get a fresh copy of the object. In order to fix this some refactoring had to happen to properly reuse cached objects. Some unittests are added to verify that symbol reuse is taking place, making use of the new unittest input feature. llvm-svn: 341503
* [DebugInfo] Common behavior for error typesAlexandre Ganea2018-08-311-2/+1
| | | | | | | | | | | | | | | 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
* [llvm-pdbutil] Support PDBs without a DBI streamAlexandre Ganea2018-08-064-47/+106
| | | | | | Differential Revision: https://reviews.llvm.org/D50258 llvm-svn: 339045
* [CodeView] Minimal support for S_UNAMESPACE recordsAlexandre Ganea2018-07-311-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D50007 llvm-svn: 338417
* [PDB] One more fix for hasing GSI records.Zachary Turner2018-07-063-1/+91
| | | | | | | | | | | | | | | | The reference implementation uses a case-insensitive string comparison for strings of equal length. This will cause the string "tEo" to compare less than "VUo". However we were using a case sensitive comparison, which would generate the opposite outcome. Switch to a case insensitive comparison. Also, when one of the strings contains non-ascii characters, fallback to a straight memcmp. The only way to really test this is with a DIA test. Before this patch, the test will fail (but succeed if link.exe is used instead of lld-link). After the patch, it succeeds even with lld-link. llvm-svn: 336464
* [llvm-pdbutil] Dump more info about globals.Zachary Turner2018-07-064-16/+60
| | | | | | | | | | | | | | | We add an option to dump the entire global / public symbol record stream. Previously we would dump globals or publics, but not both. And when we did dump them, we would always dump them in the order they were referenced by the corresponding hash streams, not in the order they were serialized in. This patch adds a lower level mode that just dumps the whole stream in serialization order. Additionally, when dumping global-extras, we now dump the hash bitmap as well as the record offset instead of dumping all zeros for the offsets. llvm-svn: 336407
* [llvm-pdbutil] Dump struct/class/union sizes in the minimal dump formatReid Kleckner2018-05-171-4/+6
| | | | llvm-svn: 332645
* llvm-pdbutil: Fix an off-by-one error.Peter Collingbourne2018-04-171-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D45740 llvm-svn: 330222
* [llvm-pdbutil] Dump first section contribution for each module.Zachary Turner2018-04-171-72/+86
| | | | | | | | | | | | | | The DBI stream contains a list of module descriptors. At the beginning of each descriptor is a structure representing the first section contribution in the output file for that module. LLD currently doesn't fill out this structure at all, but link.exe does. So as a precursor to emitting this data in LLD, we first need a way to dump it so that it can be checked. This patch adds support for the dumping, and verifies via a test that LLD emits bogus information. llvm-svn: 330208
* Remove faulty assertion in llvm-pdbutilAdrian McCarthy2018-04-161-5/+2
| | | | | | | | | | | | | | | | | | | If a class's first data member is an instance of an empty class, then an assertion in the PrettyClassLayoutGraphicalDumper would fail. The storage is reserved, but it's not marked as in use. As far as I understand, it's the assertion that's faulty, so I removed it and updated the nearby comment. Found by running llvm-pdbutil against its own PDB, and this assertion would fail on HashAdjusters, which is a HashTable whose first data member is a TraitsT, which is a PdbHashTraits<T>, which is an empty struct. (The struct has a specialization for uint32_t, but that specialization doesn't apply here because the T is actually ulittle32_t.) Differential Revision: https://reviews.llvm.org/D45645 llvm-svn: 330135
* Define InitLLVM to do common initialization all at once.Rui Ueyama2018-04-131-14/+4
| | | | | | | | | | | We have a few functions that virtually all command wants to run on process startup/shutdown. This patch adds InitLLVM class to do that all at once, so that we don't need to copy-n-paste boilerplate code to each llvm command's main() function. Differential Revision: https://reviews.llvm.org/D45602 llvm-svn: 330046
* [pdbutil] Print the checksum hex string when using the '-lines' optionAaron Smith2018-04-101-0/+6
| | | | llvm-svn: 329707
* Fix line endings (CR/LF -> LF) introduced by rL329613Alexandre Ganea2018-04-101-556/+556
| | | | | reviewer: zturner llvm-svn: 329646
* [Debuginfo][COFF] Minimal serialization support for precompiled types recordsAlexandre Ganea2018-04-092-542/+558
| | | | | | | | | | | | | 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
* [llvm-pdbutil] Display types from MSVC precompiled header object files.Zachary Turner2018-04-051-1/+8
| | | | | | | | These appear in a .debug$P section, which is exactly the same in format as a .debug$T section. So we shouldn't ignore these when dumping types. llvm-svn: 329326
* Fix a compilation failure with non MSVC compilers.Zachary Turner2018-04-041-1/+1
| | | | llvm-svn: 329209
* [llvm-pdbutil] Add the ability to explain binary files.Zachary Turner2018-04-046-113/+220
| | | | | | | | | | Using this, you can use llvm-pdbutil to export the contents of a stream to a binary file, then run explain on the binary file so that it treats the offset as an offset into the stream instead of an offset into a file. This makes it easy to compare the contents of the same stream from two different files. llvm-svn: 329207
* [llvm-pdbutil] Add an export subcommand.Zachary Turner2018-04-022-0/+70
| | | | | | | | | | | | | | | | | This command can dump the binary contents of a stream to a file. This is useful when you want to do side-by-side comparisons of a specific stream from two PDBs to examine the differences between them. You can export both of them to a file, then open them up side by side in a hex editor (for example), so as to eliminate any differences that might arise from the contents being on different blocks in the PDB. In subsequent patches I plan to improve the "explain" subcommand so that you can explain the contents of a binary file that isn't necessarily a full PDB, but one of these dumped streams, by telling the subcommand how to interpret the contents. llvm-svn: 329002
* [tools] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-013-6/+6
| | | | | | | | | | | | | | | | | | | | | | 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: JDevlieghere, zturner, echristo, dberris, friss Reviewed By: echristo Subscribers: gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D45141 llvm-svn: 328943
* Fix some signed / unsigned conversion problems.Zachary Turner2018-03-301-13/+15
| | | | llvm-svn: 328881
* [llvm-pdbutil] Dig deeper into the PDB and DBI streams when explaining.Zachary Turner2018-03-306-43/+271
| | | | | | | | | This will show more detail when using `llvm-pdbutil explain` on an offset in the DBI or PDB streams. Specifically, it will dig into individual header fields and substreams to give a more precise description of what the byte represents. llvm-svn: 328878
* [PDB] Print some more details when explaining MSF fields.Zachary Turner2018-03-291-7/+33
| | | | | | | | | | | When we determine that a field belongs to an MSF super block or the free page map, we wouldn't print any additional information. With this patch, we now print the value of the field (for super block fields) or the allocation status of the specified byte (in the case of offsets in the FPM). llvm-svn: 328808
* [PDB] Fix a bug in the explain subcommand.Zachary Turner2018-03-291-8/+10
| | | | | | | | We were trying to dig into the super block fields and print a description of the field at the specified offset, but we were printing the wrong field due to an off-by-one-field-error. llvm-svn: 328804
* Remove unused function.Zachary Turner2018-03-291-8/+0
| | | | llvm-svn: 328802
* [PDB] Add an explain subcommand.Zachary Turner2018-03-295-0/+288
| | | | | | | | | | | | | | | | | | | When investigating various things, we often have a file offset and what to know what's in the PDB at that address. For example we may be doing a binary comparison of two LLD-generated PDBs to look for sources of non-determinism, or we may wish to compare an LLD-generated PDB with a Microsoft generated PDB for sources of byte-for-byte incompatibility. In these cases, we can do a binary diff of the two files, and once we find a mismatched byte we can use explain to figure out what that byte is, immediately honining in on the problem. This patch implements this by trying to narrow the meaning of a particular file offset down as much as possible. Differential Revision: https://reviews.llvm.org/D44959 llvm-svn: 328799
* Delete pdbutil diff mode.Zachary Turner2018-03-267-1090/+0
| | | | | | | | This has been made obsolete by the fact that almost all of the things it previously checked for are no longer relevant since we can just compare bytes in a lot of places. llvm-svn: 328562
* [PDB] Make our PDBs look more like MS PDBs.Zachary Turner2018-03-234-24/+96
| | | | | | | | | | | | | | | | | | 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
* Revert "Resubmit "Support embedding natvis files in PDBs.""Zachary Turner2018-03-204-35/+0
| | | | | | | | 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-204-0/+35
| | | | | | | | | | | 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-194-35/+0
| | | | | | | 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-194-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor the PDB HashTable class.Zachary Turner2018-03-151-1/+1
| | | | | | | | | It previously only worked when the key and value types were both 4 byte integers. We now have a use case for a non trivial value type, so we need to extend it to support arbitrary value types, which means templatizing it. llvm-svn: 327647
* [PDB] Support dumping injected sources via the DIA reader.Zachary Turner2018-03-131-0/+78
| | | | | | | | | | | | | | | | | | Injected sources are basically a way to add actual source file content to your PDB. Presumably you could use this for shipping your source code with your debug information, but in practice I can only find this being used for embedding natvis files inside of PDBs. In order to effectively test LLVM's natvis file injection, we need a way to dump the injected sources of a PDB in a way that is authoritative (i.e. based on Microsoft's understanding of the PDB format, and not LLVM's). To this end, I've added support for dumping injected sources via DIA. I made a PDB file that used the /natvis option to generate a test case. Differential Revision: https://reviews.llvm.org/D44405 llvm-svn: 327428
* Fix a bug regarding a mis-identified file type in pdbutil.Zachary Turner2018-03-071-1/+1
| | | | llvm-svn: 326929
* [llvm-pdbdump] Add guard for null pointers and remove unused codeAaron Smith2018-03-074-95/+108
| | | | | | | | | | | | | | Summary: This avoids crashing when a user tries to dump a pdb with the `-native` option. Reviewers: zturner, llvm-commits, rnk Reviewed By: zturner Subscribers: mgrang Differential Revision: https://reviews.llvm.org/D44117 llvm-svn: 326863
* [llvm-pdbdump] Dump restrict type qualifierAaron Smith2018-03-053-0/+12
| | | | | | | | | | | | Reviewers: zturner, llvm-commits, rnk Reviewed By: zturner Subscribers: majnemer Differential Revision: https://reviews.llvm.org/D43639 llvm-svn: 326731
* Fix llvm-pdbutil to handle new built-in typesAdrian McCarthy2018-02-221-0/+4
| | | | | | | | | | | | | | | | Summary: The built-in PDB types enum has been extended to include char16_t and char32_t. llvm-pdbutil was hitting an llvm_unreachable because it didn't know about these new values. The new values are not yet in the DIA documentation, but are listed in the cvconst.h header that comes as part of the DIA SDK. Reviewers: asmith, zturner, rnk Subscribers: stella.stamenova, llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D43646 llvm-svn: 325838
* Fix emission of PDB string table.Zachary Turner2018-02-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was originally reported as a bug with the symptom being "cvdump crashes when printing an LLD-linked PDB that has an S_FILESTATIC record in it". After some additional investigation, I determined that this was a symptom of a larger problem, and in fact the real problem was in the way we emitted the global PDB string table. As evidence of this, you can take any lld-generated PDB, run cvdump -stringtable on it, and it would return no results. My hypothesis was that cvdump could not *find* the string table to begin with. Normally it would do this by looking in the "named stream map", finding the string /names, and using its value as the stream index. If this lookup fails, then cvdump would fail to load the string table. To test this hypothesis, I looked at the name stream map generated by a link.exe PDB, and I emitted exactly those bytes into an LLD-generated PDB. Suddenly, cvdump could read our string table! This code has always been hacky and we knew there was something we didn't understand. After all, there were some comments to the effect of "we have to emit strings in a specific order, otherwise things don't work". The key to fixing this was finally understanding this. The way it works is that it makes use of a generic serializable hash map that maps integers to other integers. In this case, the "key" is the offset into a buffer, and the value is the stream number. If you index into the buffer at the offset specified by a given key, you find the name. The underlying cause of all these problems is that we were using the identity function for the hash. i.e. if a string's offset in the buffer was 12, the hash value was 12. Instead, we need to hash the string *at that offset*. There is an additional catch, in that we have to compute the hash as a uint32 and then truncate it to uint16. Making this work is a little bit annoying, because we use the same hash table in other places as well, and normally just using the identity function for the hash function is actually what's desired. I'm not totally happy with the template goo I came up with, but it works in any case. The reason we never found this bug through our own testing is because we were building a /parallel/ hash table (in the form of an llvm::StringMap<>) and doing all of our lookups and "real" hash table work against that. I deleted all of that code and now everything goes through the real hash table. Then, to test it, I added a unit test which adds 7 strings and queries the associated values. I test every possible insertion order permutation of these 7 strings, to verify that it really does work as expected. Differential Revision: https://reviews.llvm.org/D43326 llvm-svn: 325386
OpenPOWER on IntegriCloud