summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-pdbdump
Commit message (Collapse)AuthorAgeFilesLines
* Rename llvm-pdbdump -> llvm-pdbutil.Zachary Turner2017-06-0943-6579/+0
| | | | | | | | | | This is to reflect the evolving nature of the tool as being useful for more than just dumping PDBs, as it can do many other things. Differential Revision: https://reviews.llvm.org/D34062 llvm-svn: 305106
* [llvm-pdbdump] Fix -Wpessimizing-move warnings.Craig Topper2017-06-091-2/+2
| | | | llvm-svn: 305050
* [pdb] Don't crash on unknown debug subsections.Zachary Turner2017-06-092-0/+14
| | | | | | | | More and more unknown debug subsection kinds are being discovered so we should make it possible to dump these and display the bytes. llvm-svn: 305041
* [CodeView] Support remaining debug subsection typesZachary Turner2017-06-094-14/+102
| | | | | | | | | | | | | | | | This adds support for Symbols, StringTable, and FrameData subsection types. Even though these subsections rarely if ever appear in a PDB file (they are usually in object files), there's no theoretical reason why they *couldn't* appear in a PDB. The real issue though is that in order to add support for dumping and writing them (which will be useful for object files), we need a way to test them. And since there is no support for reading and writing them to / from object files yet, making PDB support them is the best way to both add support for the underlying format and add support for tests at the same time. Later, when we go to add support for reading / writing them from object files, we'll need only minimal changes in the underlying read/write code. llvm-svn: 305037
* [llvm-pdbdump] Support native ordering of subsections in raw mode.Zachary Turner2017-06-085-262/+101
| | | | | | | | | | | | | This is the same change for the YAML Output style applied to the raw output style. Previously we would queue up all subsections until every one had been read, and then output them in a pre- determined order. This was because some subsections need to be read first in order to properly dump later subsections. This patch allows them to be dumped in the order they appear. Differential Revision: https://reviews.llvm.org/D34015 llvm-svn: 305034
* [llvm-pdbdump] Improve consistency among subcommands.Zachary Turner2017-06-084-100/+154
| | | | | | | | | | | | | | | The pdb2yaml and raw subcommands did something very similar but with a different output format, and they used a lot of the same command line options, but each one re-implemented the command line option with slightly different spellings / options. This patch merges them together into a single definition which is shared by both subcommands. This new syntax also allows for more flexibility in the way debug subsections are dumped. Differential Revision: https://reviews.llvm.org/D33996 llvm-svn: 305032
* [PDB] Don't crash on /debug:fastlink PDBs.Zachary Turner2017-06-081-64/+68
| | | | | | | | | | Apparently support for /debug:fastlink PDBs isn't part of the DIA SDK (!), and it was causing llvm-pdbdump to crash because we weren't checking for a null pointer return value. This manifests when calling findChildren on the IDiaSymbol, and it returns E_NOTIMPL. llvm-svn: 304982
* [CodeView] Handle Cross Module Imports and Exports.Zachary Turner2017-06-054-8/+63
| | | | | | | | | | | | | | | While it's not entirely clear why a compiler or linker might put this information into an object or PDB file, one has been spotted in the wild which was causing llvm-pdbdump to crash. This patch adds support for reading-writing these sections. Since I don't know how to get one of the native tools to generate this kind of debug info, the only test here is one in which we feed YAML into the tool to produce a PDB and then spit out YAML from the resulting PDB and make sure that it matches. llvm-svn: 304738
* [PDB] Fix use after free.Zachary Turner2017-06-033-5/+6
| | | | | | | | | | | | | | | | | | | | | | | Previously MappedBlockStream owned its own BumpPtrAllocator that it would allocate from when a read crossed a block boundary. This way it could still return the user a contiguous buffer of the requested size. However, It's not uncommon to open a stream, read some stuff, close it, and then save the information for later. After all, since the entire file is mapped into memory, the data should always be available as long as the file is open. Of course, the exception to this is when the data isn't *in* the file, but rather in some buffer that we temporarily allocated to present this contiguous view. And this buffer would get destroyed as soon as the strema was closed. The fix here is to force the user to specify the allocator, this way it can provide an allocator that has whatever lifetime it chooses. Differential Revision: https://reviews.llvm.org/D33858 llvm-svn: 304623
* [CodeView] Support CodeView subsections in any order.Zachary Turner2017-06-026-183/+34
| | | | | | | | | | | | | | | Previously we would expect certain subsections to appear in a certain order because some subsections would reference other subsections, but in practice we need to support arbitrary orderings since some object file and PDB file producers generate them this way. This also paves the way for supporting Yaml <-> Object File conversion of CodeView, since Object Files typically have quite a large number of subsections in their debug info. Differential Revision: https://reviews.llvm.org/D33807 llvm-svn: 304588
* [CodeView] Properly align symbol records on read/write.Zachary Turner2017-06-012-4/+7
| | | | | | | | | | | | | | | | | Object files have symbol records not aligned to any particular boundary (e.g. 1-byte aligned), while PDB files have symbol records padded to 4-byte aligned boundaries. Since they share the same reading / writing code, we have to provide an option to specify the alignment and propagate it up to the producer or consumer who knows what the alignment is supposed to be for the given container type. Added a test for this by modifying the existing PDB -> YAML -> PDB round-tripping code to round trip symbol records as well as types. Differential Revision: https://reviews.llvm.org/D33785 llvm-svn: 304484
* [ObjectYAML] Split CodeViewYAML into 3 pieces.Zachary Turner2017-05-314-3/+4
| | | | | | | | | The code was a mess and disorganized due to the sheer amount of it being in one file. So I'm splitting this into three files. One for CodeView types, one for CodeView symbols, and one for CodeView debug subsections. NFC. llvm-svn: 304278
* [ObjectYAML] Clean up the CodeView headers a bit.Zachary Turner2017-05-311-1/+0
| | | | | | | | | | | | CodeViewYAML.h attempts to hide the details of many of the CodeView yaml structures and types, but at the same time it exposes the mapping traits for them to external users of the header. This patch just hides these in the implementation files so that the interface is kept as simple as possible. llvm-svn: 304263
* [CodeView] Move CodeView symbol yaml logic to ObjectYAML.Zachary Turner2017-05-307-514/+7
| | | | | | | | This continues the effort to get the CodeView YAML parsing logic into ObjectYAML. After this patch, the only missing piece will be the CodeView debug symbol subsections. llvm-svn: 304256
* [CodeView] Move CodeView YAML code to ObjectYAML.Zachary Turner2017-05-3013-1125/+69
| | | | | | | | | | | | | | | | | | | | | | This is the beginning of an effort to move the codeview yaml reader / writer into ObjectYAML so that it can be shared. Currently the only consumer / producer of CodeView YAML is llvm-pdbdump, but CodeView can exist outside of PDB files, and indeed is put into object files and passed to the linker to produce PDB files. Furthermore, there are subtle differences in the types of records that show up in object file CodeView vs PDB file CodeView, but they are otherwise 99% the same. By having this code in ObjectYAML, we can have llvm-pdbdump reuse this code, while teaching obj2yaml and yaml2obj to use this syntax for dealing with object files that can contain CodeView. This patch only adds support for CodeView type information to ObjectYAML. Subsequent patches will add support for CodeView symbol information. llvm-svn: 304248
* [CodeView] Rename ModuleDebugFragment -> DebugSubsection.Zachary Turner2017-05-305-40/+39
| | | | | | | This is more concise, and matches the terminology used in other parts of the codebase more closely. llvm-svn: 304218
* [llvm-pdbdump] pdb2yaml: add an -all option to dump everything we canBob Haarman2017-05-263-0/+18
| | | | | | | | | | | | Reviewers: amccarth, rnk, zturner Reviewed By: zturner Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D33613 llvm-svn: 304047
* [llvm-pdbdump] Don't crash when displaying padding.Zachary Turner2017-05-261-1/+2
| | | | | | | | | | | | | | | | | | We have a lot of complicated logic to determine where padding is in a record, and the debug info doesn't always provide enough information to figure it out with laser precision. In this case we were putting the padding in the wrong place causing an out of bounds access on a BitVector. Right now we decide that any trailing padding of a child type will be truncated during record layout, but this is only true insofar as the class still is sized properly to end on an alignment boundary, which the algorithm doesn't yet know about. For now, just don't crash, even though we display padding twice in this case. llvm-svn: 303946
* [llvm-pdbdump] [yaml2pdb] always include object file name in module infoBob Haarman2017-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, the yaml2pdb subcommand of llvm-pdbdump only included object file names in module info if a module info stream was present. This change makes it so that we include the object file name even if there is no module info stream for the module. As a result, running llvm-pdbdump pdb2yaml -dbi-module-info original.pdb > original.yaml && llvm-pdbdump yaml2pdb -pdb=new.pdb original.yaml && llvm-pdbdump pdb2yaml -dbi-module-info new.pdb > new.yaml now produces identical original.yaml and new.yaml files. Reviewers: amccarth, zturner Reviewed By: zturner Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D33463 llvm-svn: 303891
* Fix broken build.Zachary Turner2017-05-241-2/+2
| | | | llvm-svn: 303711
* [PDB] Hash types up front when merging types instead of using StringMapReid Kleckner2017-05-231-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First, StringMap uses llvm::HashString, which is only good for short identifiers and really bad for large blobs of binary data like type records. Moving to `DenseMap<StringRef, TypeIndex>` with some tricks for memory allocation fixes that. Unfortunately, that didn't buy very much performance. Profiling showed that we spend a long time during DenseMap growth rehashing existing entries. Also, in general, DenseMap is faster when the keys are small. This change takes that to the logical conclusion by introducing a small wrapper value type around a pointer to key data. The key data contains a precomputed hash, the original record data (pointer and size), and the type index, which is the "value" of our original map. This reduces the time to produce llvm-as.exe and llvm-as.pdb from ~15s on my machine to 3.5s, which is about a 4x improvement. Reviewers: zturner, inglorion, ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33428 llvm-svn: 303665
* Revert "Make TypeSerializer's StringMap use the same allocator."Zachary Turner2017-05-231-2/+2
| | | | | | | | This reverts commit e34ccb7b57da25cc89ded913d8638a2906d1110a. This is causing failures on the ASAN bots. llvm-svn: 303640
* Implement various flavors of type merging.Zachary Turner2017-05-221-9/+9
| | | | | | | | | | | | | | Previous algotirhm assumed that types and ids are in a single unified stream. For inputs that come from object files, this is the case. But if the input is already a PDB, or is the result of a previous merge, then the types and ids will already have been split up, in which case we need an algorithm that can accept operate on independent streams of types and ids that refer across stream boundaries to each other. Differential Revision: https://reviews.llvm.org/D33417 llvm-svn: 303577
* Make TypeSerializer's StringMap use the same allocator.Zachary Turner2017-05-221-2/+2
| | | | llvm-svn: 303576
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-199-82/+73
| | | | | | | | | | | | This was originally reverted because it was a breaking a bunch of bots and the breakage was not surfacing on Windows. After much head-scratching this was ultimately traced back to a bug in the lit test runner related to its pipe handling. Now that the bug in lit is fixed, Windows correctly reports these test failures, and as such I have finally (hopefully) fixed all of them in this patch. llvm-svn: 303446
* Fix compilation failure.Zachary Turner2017-05-191-1/+1
| | | | llvm-svn: 303410
* Revert "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-199-74/+84
| | | | | | | | | | | | | | | | | | This is a squash of ~5 reverts of, well, pretty much everything I did today. Something is seriously broken with lit on Windows right now, and as a result assertions that fire in tests are triggering failures. I've been breaking non-Windows bots all day which has seriously confused me because all my tests have been passing, and after running lit with -a to view the output even on successful runs, I find out that the tool is crashing and yet lit is still reporting it as a success! At this point I don't even know where to start, so rather than leave the tree broken for who knows how long, I will get this back to green, and then once lit is fixed on Windows, hopefully hopefully fix the remaining set of problems for real. llvm-svn: 303409
* Fix some build errors and warnings.Zachary Turner2017-05-182-2/+2
| | | | llvm-svn: 303391
* [CodeView] Raise the source to ID map out of the TypeStreamMerger.Zachary Turner2017-05-181-4/+8
| | | | | | | This map will be needed to rewrite symbol streams after re-writing the corresponding type streams. llvm-svn: 303390
* [llvm-pdbdump] Add the ability to merge PDBs.Zachary Turner2017-05-181-0/+68
| | | | | | | | | | | | | | | Merging PDBs is a feature that will be used heavily by the linker. The functionality already exists but does not have deep test coverage because it's not easily exposed through any tools. This patch aims to address that by adding the ability to merge PDBs via llvm-pdbdump. It takes arbitrarily many PDBs and outputs a single PDB. Using this new functionality, a test is added for merging type records. Future patches will add the ability to merge symbol records, module information, etc. llvm-svn: 303389
* [CodeView] Provide a common interface for type collections.Zachary Turner2017-05-188-83/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now we have multiple notions of things that represent collections of types. Most commonly used are TypeDatabase, which is supposed to keep mappings from TypeIndex to type name when reading a type stream, which happens when reading PDBs. And also TypeTableBuilder, which is used to build up a collection of types dynamically which we will later serialize (i.e. when writing PDBs). But often you just want to do some operation on a collection of types, and you may want to do the same operation on any kind of collection. For example, you might want to merge two TypeTableBuilders or you might want to merge two type streams that you loaded from various files. This dichotomy between reading and writing is responsible for a lot of the existing code duplication and overlapping responsibilities in the existing CodeView library classes. For example, after building up a TypeTableBuilder with a bunch of type records, if we want to dump it we have to re-invent a bunch of extra glue because our dumper takes a TypeDatabase or a CVTypeArray, which are both incompatible with TypeTableBuilder. This patch introduces an abstract base class called TypeCollection which is shared between the various type collection like things. Wherever we previously stored a TypeDatabase& in some common class, we now store a TypeCollection&. The advantage of this is that all the details of how the collection are implemented, such as lazy deserialization of partial type streams, is completely transparent and you can just treat any collection of types the same regardless of where it came from. Differential Revision: https://reviews.llvm.org/D33293 llvm-svn: 303388
* [llvm-pdbdump] in yaml2pdb, generate default output filename if none givenBob Haarman2017-05-171-4/+10
| | | | | | | | | | | | | | | | | | | | Summary: llvm-pdbdump yaml2pdb used to fail with a misleading error message ("An I/O error occurred on the file system") if no output file was specified. This change adds an assert to PDBFileBuilder to check that an output file name is specified, and makes llvm-pdbdump generate an output file name based on the input file name if no output file name is explicitly specified. Reviewers: amccarth, zturner Reviewed By: zturner Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D33296 llvm-svn: 303299
* [CodeView] Simplify the use of visiting type records & streams.Zachary Turner2017-05-174-92/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is often a lot of boilerplate code required to visit a type record or type stream. The #1 use case is that you have a sequence of bytes that represent one or more records, and you want to deserialize each one, switch on it, and call a callback with the deserialized record that the user can examine. Currently this requires at least 6 lines of code: codeview::TypeVisitorCallbackPipeline Pipeline; Pipeline.addCallbackToPipeline(Deserializer); Pipeline.addCallbackToPipeline(MyCallbacks); codeview::CVTypeVisitor Visitor(Pipeline); consumeError(Visitor.visitTypeRecord(Record)); With this patch, it becomes one line of code: consumeError(codeview::visitTypeRecord(Record, MyCallbacks)); This is done by having the deserialization happen internally inside of the visitTypeRecord function. Since this is occasionally not desirable, the function provides a 3rd parameter that can be used to change this behavior. Hopefully this can significantly reduce the barrier to entry to using the visitation infrastructure. Differential Revision: https://reviews.llvm.org/D33245 llvm-svn: 303271
* [llvm-pdbdump] Add the option to sort functions and data.Zachary Turner2017-05-144-11/+136
| | | | llvm-svn: 302998
* [CodeView] Add a random access type visitor.Zachary Turner2017-05-121-1/+1
| | | | | | | | | | | | This adds a visitor that is capable of accessing type records randomly and caching intermediate results that it learns about during partial linear scans. This yields amortized O(1) access to a type stream even though type streams cannot normally be indexed. Differential Revision: https://reviews.llvm.org/D33009 llvm-svn: 302936
* [CodeView] Reserve TypeDatabase records up front.Zachary Turner2017-05-052-4/+4
| | | | | | | | | | | | | Most of the time we know exactly how many type records we have in a list, and we want to use the visitor to deserialize them into actual records in a database. Previously we were just using push_back() every time without reserving the space up front in the vector. This is obviously terrible from a performance standpoint, and it's not uncommon to have PDB files with half a million type records, where the performance degredation was quite noticeable. llvm-svn: 302302
* [pdb] Don't verify TPI hash values up front.Zachary Turner2017-05-041-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | Verifying the hash values as we are currently doing results in iterating every type record before the user even tries to access the first one, and the API user has no control over, or ability to hook into this process. As a result, when the user wants to iterate over types to print them or index them, this results in a second iteration over the same list of types. When there's upwards of 1,000,000 type records, this is obviously quite undesirable. This patch raises the verification outside of TpiStream , and llvm-pdbdump hooks a hash verification visitor into the normal dumping process. So we still verify the hash records, but we can do it while not requiring a second iteration over the type stream. Differential Revision: https://reviews.llvm.org/D32873 llvm-svn: 302206
* [PDB] Don't build the entire source file list up front.Zachary Turner2017-05-043-36/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I tried to run llvm-pdbdump on a very large (~1.5GB) PDB to try and identify show-stopping performance problems. This patch addresses the first such problem. When loading the DBI stream, before anyone has even tried to access a single record, we build an in memory map of every source file for every module. In the particular PDB I was using, this was over 85 million files. Specifically, the complexity is O(m*n) where m is the number of modules and n is the average number of source files (including headers) per module. The whole reason for doing this was so that we could have constant time access to any module and any of its source file lists. However, we can still get O(1) access to the source file list for a given module with a simple O(m) precomputation, and access to the list of modules is already O(1) anyway. So this patches reduces the O(m*n) up-front precomputation to an O(m) one, where n is ~6,500 and n*m is about 85 million in my pathological test case. Differential Revision: https://reviews.llvm.org/D32870 llvm-svn: 302205
* [llvm-pdbdump] Only build the TypeDatabase if necessary.Zachary Turner2017-05-042-41/+77
| | | | | | | | | Building the type database is expensive, and can take multiple minutes for large PDBs. But we only need it in certain cases depending on what command line options are specified. So only build it when we know we're about to need it. llvm-svn: 302204
* Remove unused private field.Zachary Turner2017-05-031-1/+1
| | | | llvm-svn: 302069
* [CodeView] Use actual strings for dealing with checksums and lines.Zachary Turner2017-05-031-40/+13
| | | | | | | | | | | | | | | | | | | | | The raw CodeView format references strings by "offsets", but it's confusing what table the offset refers to. In the case of line number information, it's an offset into a buffer of records, and an indirection is required to get another offset into a different table to find the final string. And in the case of checksum information, there is no indirection, and the offset refers directly to the location of the string in another buffer. This would be less confusing if we always just referred to the strings by their value, and have the library be smart enough to correctly resolve the offsets on its own from the right location. This patch makes that possible. When either reading or writing, all the user deals with are strings, and the library does the appropriate translations behind the scenes. llvm-svn: 302053
* [llvm-readobj] Update readobj to re-use parsing code.Zachary Turner2017-05-033-19/+42
| | | | | | | | | | llvm-readobj hand rolls some CodeView parsing code for string tables, so this patch updates it to re-use some of the newly introduced parsing code in LLVMDebugInfoCodeView. Differential Revision: https://reviews.llvm.org/D32772 llvm-svn: 302052
* Rename pdb::StringTable -> pdb::PDBStringTable.Zachary Turner2017-05-023-4/+4
| | | | | | | | With the forthcoming codeview::StringTable which a pdb::StringTable would hold an instance of as one member, this ambiguity becomes confusing. Rename to PDBStringTable to avoid this. llvm-svn: 301948
* [PDB/CodeView] Read/write codeview inlinee line information.Zachary Turner2017-05-029-26/+203
| | | | | | | | Previously we wrote line information and file checksum information, but we did not write information about inlinee lines and functions. This patch adds support for that. llvm-svn: 301936
* [CodeView] Write CodeView line information.Zachary Turner2017-05-013-4/+66
| | | | | | Differential Revision: https://reviews.llvm.org/D32716 llvm-svn: 301882
* [PDB/CodeView] Rename some classes.Zachary Turner2017-05-016-18/+16
| | | | | | | | | | | | In preparation for introducing writing capabilities for each of these classes, I would like to adopt a Foo / FooRef naming convention, where Foo indicates that the class can manipulate and serialize Foos, and FooRef indicates that it is an immutable view of an existing Foo. In other words, Foo is a writer and FooRef is a reader. This patch names some existing readers to conform to the FooRef convention, while offering no functional change. llvm-svn: 301810
* Remove unused private field.Zachary Turner2017-04-291-4/+3
| | | | llvm-svn: 301738
* [llvm-pdbdump] Abstract some of the YAML/Raw printing code.Zachary Turner2017-04-297-165/+288
| | | | | | | | | There is a lot of duplicate code for printing line info between YAML and the raw output printer. This introduces a base class that can be shared between the two, and makes some minor cleanups in the process. llvm-svn: 301728
* [llvm-pdbdump] Allow printing only a portion of a stream.Zachary Turner2017-04-283-5/+45
| | | | | | | | | | | | When dumping raw data from a stream, you might know the offset of a certain record you're interested in, as well as how long that record is. Previously, you had to dump the entire stream and wade through the bytes to find the interesting record. This patch allows you to specify an offset and length on the command line, and it will only dump the requested range. llvm-svn: 301607
* Fix a few pedantic warnings.Frederich Munch2017-04-271-5/+5
| | | | | | | | | | | | Reviewers: zturner, hansw, hans Reviewed By: hans Subscribers: hans, llvm-commits Differential Revision: https://reviews.llvm.org/D32611 llvm-svn: 301595
OpenPOWER on IntegriCloud