summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* [llvm-pdbdump] Support native ordering of subsections in raw mode.Zachary Turner2017-06-082-6/+42
| | | | | | | | | | | | | 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
* [PDB] Don't crash on /debug:fastlink PDBs.Zachary Turner2017-06-081-2/+5
| | | | | | | | | | 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
* Update libdeps to add BinaryFormat, introduced in r304864.NAKAMURA Takumi2017-06-071-1/+1
| | | | llvm-svn: 304869
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-0713-13/+16
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Fix uninitialized read.Zachary Turner2017-06-062-8/+12
| | | | llvm-svn: 304846
* Introduce -brief command line option to llvm-dwarfdumpAdrian Prantl2017-06-063-20/+25
| | | | | | | | | | | | | This patch introduces a new command line option, called brief, to llvm-dwarfdump. When -brief is used, the attribute forms for the .debug_info section will not be emitted to output. Patch by Spyridoula Gravani! rdar://problem/21474365 Differential Revision: https://reviews.llvm.org/D33867 llvm-svn: 304844
* Fix another ordering constraint with windows.h and comment aboutChandler Carruth2017-06-061-1/+3
| | | | | | a revers constraint that we got right (by chance). llvm-svn: 304792
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-0636-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [DWARF] Adding support for the DWARF v5 string offsets table ↵Wolfgang Pieb2017-06-063-33/+176
| | | | | | | | | | (consumer/reader part only). Reviewers: dblaikie, aprantl Differential Revision: https://reviews.llvm.org/D32779 llvm-svn: 304759
* [CodeView] Fix endianness bug.Zachary Turner2017-06-051-1/+3
| | | | | | | We should be outputting in little endian, but we were writing in host endianness. llvm-svn: 304741
* [CodeView] Handle Cross Module Imports and Exports.Zachary Turner2017-06-057-10/+170
| | | | | | | | | | | | | | | 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-039-51/+59
| | | | | | | | | | | | | | | | | | | | | | | 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-025-54/+39
| | | | | | | | | | | | | | | 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
* Fix 2 more -Wreorder warnings.Zachary Turner2017-06-011-4/+4
| | | | llvm-svn: 304494
* [CodeView] Properly align symbol records on read/write.Zachary Turner2017-06-016-21/+51
| | | | | | | | | | | | | | | | | 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
* [DWARF] Introduce Dump OptionsAdrian Prantl2017-06-012-4/+7
| | | | | | | | | | | This commit introduces a structure that holds all the flags that control the pretty printing of dwarf output. Patch by Spyridoula Gravani! Differential Revision: https://reviews.llvm.org/D33749 llvm-svn: 304446
* [CodeView] Move CodeView YAML code to ObjectYAML.Zachary Turner2017-05-305-8/+8
| | | | | | | | | | | | | | | | | | | | | | 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
* Added missing break.Galina Kistanova2017-05-301-0/+1
| | | | llvm-svn: 304230
* [CodeView] Add more DebugSubsection implementations.Zachary Turner2017-05-309-28/+120
| | | | | | | | This adds implementations for Symbols and FrameData, and renames the existing codeview::StringTable class to conform to the DebugSectionStringTable convention. llvm-svn: 304222
* [CodeView] Rename ModuleDebugFragment -> DebugSubsection.Zachary Turner2017-05-3011-228/+219
| | | | | | | This is more concise, and matches the terminology used in other parts of the codebase more closely. llvm-svn: 304218
* Recommit "[DWARF] - Make collectAddressRanges() return section index in ↵George Rimar2017-05-274-34/+50
| | | | | | | | | | | | | | | | | | | | | | addition to Low/High PC" With fix of uninitialized variable. Original commit message: This change is intended to use for LLD in D33183. Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to. Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's. That not only was slow, but also complicated implementation and was the reason of incorrect behavior when sections share the same offsets, like D33176 shows. This patch makes DWARF parsers to return section index as well. That solves problem mentioned above. Differential revision: https://reviews.llvm.org/D33184 llvm-svn: 304078
* Revert r304002 "[DWARF] - Make collectAddressRanges() return section index ↵George Rimar2017-05-264-49/+34
| | | | | | | | in addition to Low/High PC" Revert it again. Now another bot unhappy: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/8750 llvm-svn: 304011
* [DWARF] - Make collectAddressRanges() return section index in addition to ↵George Rimar2017-05-264-34/+49
| | | | | | | | | | | | | | | | | | Low/High PC This change is intended to use for LLD in D33183. Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to. Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's. That not only was slow, but also complicated implementation and was the reason of incorrect behavior when sections share the same offsets, like D33176 shows. This patch makes DWARF parsers to return section index as well. That solves problem mentioned above. Differential revision: https://reviews.llvm.org/D33184 llvm-svn: 304002
* Revert "[DWARF] - Make collectAddressRanges() return section index in ↵George Rimar2017-05-264-47/+34
| | | | | | | | | | | | addition to Low/High PC" Broked BB again: TEST 'LLVM :: DebugInfo/X86/dbg-value-regmask-clobber.ll' FAILED ... LLVM ERROR: Section was outside of section table. llvm-svn: 303984
* Recommit r303978 "[DWARF] - Make collectAddressRanges() return section index ↵George Rimar2017-05-264-34/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | in addition to Low/High PC" With fix of test compilation. Initial commit message: This change is intended to use for LLD in D33183. Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to. Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's. That not only was slow, but also complicated implementation and was the reason of incorrect behavior when sections share the same offsets, like D33176 shows. This patch makes DWARF parsers to return section index as well. That solves problem mentioned above. Differential revision: https://reviews.llvm.org/D33184 llvm-svn: 303983
* Revert r303978 "[DWARF] - Make collectAddressRanges() return section index ↵George Rimar2017-05-264-47/+34
| | | | | | | | in addition to Low/High PC" It failed BB. llvm-svn: 303981
* [DWARF] - Make collectAddressRanges() return section index in addition to ↵George Rimar2017-05-264-34/+47
| | | | | | | | | | | | | | | | | | | | | | Low/High PC This change is intended to use for LLD in D33183. Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to. Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's. That not only was slow, but also complicated implementation and was the reason of incorrect behavior when sections share the same offsets, like D33176 shows. This patch makes DWARF parsers to return section index as well. That solves problem mentioned above. Differential revision: https://reviews.llvm.org/D33184 llvm-svn: 303978
* Remove unused member.Zachary Turner2017-05-251-2/+0
| | | | llvm-svn: 303942
* [CV Type Merging] Find nested type indices faster.Zachary Turner2017-05-253-347/+413
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merging two type streams is one of the most time consuming parts of generating a PDB, and as such it needs to be as fast as possible. The visitor abstractions used for interoperating nicely with many different types of inputs and outputs have been used widely and help greatly for testability and implementing tools, but the abstractions build up and get in the way of performance. This patch removes all of the visitation stuff from the type stream merger, essentially re-inventing the leaf / member switch and loop, but at a very low level. This allows us many other optimizations, such as not actually deserializing *any* records (even member records which don't describe their own length), as the operation of "figure out how long this record is" is somewhat faster than "figure out how long this record *and* get all its fields out". Furthermore, whereas before we had to deserialize, re-write type indices, then re-serialize, now we don't have to do any of those 3 steps. We just find out where the type indices are and pull them directly out of the byte stream and re-write them. This is worth a 50-60% performance increase. On top of all other optimizations that have been applied this week, I now get the following numbers when linking lld.exe and lld.pdb MSVC: 25.67s Before This Patch: 18.59s After This Patch: 8.92s So this is a huge performance win. Differential Revision: https://reviews.llvm.org/D33564 llvm-svn: 303935
* [lld] Fix a bug where we continually re-follow type servers.Zachary Turner2017-05-251-5/+6
| | | | | | | | | | | | | | | | | | | Originally this was intended to be set up so that when linking a PDB which refers to a type server, it would only visit the PDB once, and on subsequent visitations it would just skip it since all the records had already been added. Due to some C++ scoping issues, this was not occurring and it was revisiting the type server every time, which caused every record to end up being thrown away on all subsequent visitations. This doesn't affect the performance of linking clang-cl generated object files because we don't use type servers, but when linking object files and libraries generated with /Zi via MSVC, this means only 1 object file has to be linked instead of N object files, so the speedup is quite large. llvm-svn: 303920
* [CodeView Type Merging] Don't keep re-allocating temp serializer.Zachary Turner2017-05-252-9/+19
| | | | | | | | | | | | | | | | Previously, every time we wanted to serialize a field list record, we would create a new copy of FieldListRecordBuilder, which would in turn create a temporary instance of TypeSerializer, which itself had a std::vector<> that was about 128K in size. So this 128K allocation was happening every time. We can re-use the same instance over and over, we just have to clear its internal hash table and seen records list between each run. This saves us from the constant re-allocations. This is worth an ~18.5% speed increase (3.75s -> 3.05s) in my tests. Differential Revision: https://reviews.llvm.org/D33506 llvm-svn: 303919
* [pdb] pad source file name buffer at the end instead of the beginningBob Haarman2017-05-251-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | Summary: DbiStreamBuilder calculated the offset of the source file names inside the file info substream as the size of the file info substream minus the size of the file names. Since the file info substream is padded to a multiple of 4 bytes, this caused the first file name to be aligned on a 4-byte boundary. By contrast, DbiModuleList would read the file names immediately after the file name offset table, without skipping to the next 4-byte boundary. This change makes it so that the file names are written to the location where DbiModuleList expects them, and puts any necessary padding for the file info substream after the file names instead of before it. Reviewers: amccarth, rnk, zturner Reviewed By: amccarth, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33475 llvm-svn: 303917
* Fix a bug in MappedBlockStream.Zachary Turner2017-05-251-17/+15
| | | | | | | | | | It was using the number of blocks of the entire PDB file as the number of blocks of each stream that was created. This was only an issue in the readLongestContiguousChunk function, which was never called prior. This bug surfaced when I updated an algorithm to use this function and the algorithm broke. llvm-svn: 303916
* [CodeView Type Merging] Avoid record deserialization when possible.Zachary Turner2017-05-254-145/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A profile shows the majority of time doing type merging is spent deserializing records from sequences of bytes into friendly C++ structures that we can easily access members of in order to find the type indices to re-write. Records are prefixed with their length, however, and most records have type indices that appear at fixed offsets in the record. For these records, we can save some cycles by just looking at the right place in the byte sequence and re-writing the value, then skipping the record in the type stream. This saves us from the costly deserialization of examining every field, including potentially null terminated strings which are the slowest, even though it was unnecessary to begin with. In addition, we apply another optimization. Previously, after deserializing a record and re-writing its type indices, we would unconditionally re-serialize it in order to compute the hash of the re-written record. This would result in an alloc and memcpy for every record. If no type indices were re-written, however, this was an unnecessary allocation. In this patch re-writing is made two phase. The first phase discovers the indices that need to be rewritten and their new values. This information is passed through to the de-duplication code, which only copies and re-writes type indices in the serialized byte sequence if at least one type index is different. Some records have type indices which only appear after variable length strings, or which have lists of type indices, or various other situations that can make it tricky to make this optimization. While I'm not giving up on optimizing these cases as well, for now we can get the easy cases out of the way and lay the groundwork for more complicated cases later. This patch yields another 50% speedup on top of the already large speedups submitted over the past 2 days. In two tests I have run, I went from 9 seconds to 3 seconds, and from 16 seconds to 8 seconds. Differential Revision: https://reviews.llvm.org/D33480 llvm-svn: 303914
* Don't do a full scan of the type stream before processing records.Zachary Turner2017-05-241-11/+11
| | | | | | | | | | | | | LazyRandomTypeCollection is designed for random access, and in order to provide this it lazily indexes ranges of types. In the case of types from an object file, there is no partial index to build off of, so it has to index the full stream up front. However, merging types only requires sequential access, and when that is needed, this extra work is simply wasted. Changing the algorithm to work on sequential arrays of types rather than random access type collections eliminates this up front scan. llvm-svn: 303707
* [CodeView] Eliminate redundant hashes and allocations.Zachary Turner2017-05-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When writing field list records, we would construct a temporary type serializer that shared a bump ptr allocator with the rest of the application, so anything allocated from here would live forever. Furthermore, this temporary serializer had all the properties of a full blown serializer including record hashing and de-duplication. These features are required when you're merging multiple type streams into each other, because different streams may contain identical records, but records from the same type stream will never collide with each other. So all of this hashing was unnecessary. To solve this, two fixes are made: 1) The temporary serializer keeps its own bump ptr allocator instead of sharing a global one. When it's finished, all of its memory is freed. 2) Instead of using the same temporary serializer for the life of an entire type stream, we use it only for the life of a single field list record and delete it when the field list record is completed. This way the hash table will not grow as other records from the same type stream get inserted. Further improvements could eliminate hashing entirely from this codepath. This reduces the link time by 85% in my test, from 1 minute to 9 seconds. llvm-svn: 303676
* Speculative build fix for non-WindowsReid Kleckner2017-05-231-0/+2
| | | | llvm-svn: 303667
* [PDB] Hash types up front when merging types instead of using StringMapReid Kleckner2017-05-232-66/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-232-13/+32
| | | | | | | | This reverts commit e34ccb7b57da25cc89ded913d8638a2906d1110a. This is causing failures on the ASAN bots. llvm-svn: 303640
* libDebugInfo: Support symbolizing using DWP filesDavid Blaikie2017-05-232-13/+44
| | | | llvm-svn: 303609
* FIX: Remove debugging assert left in previous commitDavid Blaikie2017-05-231-1/+0
| | | | | | Sorry for the bot noise. llvm-svn: 303592
* libDebugInfo: Avoid independently parsing the same .dwo file for two ↵David Blaikie2017-05-232-27/+38
| | | | | | | | | separate CUs residing there NFC, just an optimization. Will be building on this for DWP support shortly. llvm-svn: 303591
* Implement various flavors of type merging.Zachary Turner2017-05-222-76/+175
| | | | | | | | | | | | | | 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-222-32/+13
| | | | llvm-svn: 303576
* libDebugInfo/DWARF: Apply relocations for debug_addr addresses in object filesDavid Blaikie2017-05-222-20/+22
| | | | | | | | | | | llvm-symbolizer would fail to symbolize addresses in unlinked object files when handling .dwo file data because the addresses would not be relocated in the same way as the ranges in the skeleton CU in the object file. Fix that so object files can be symbolized the same as executables. llvm-svn: 303532
* llvm-symbolizer: Support multiple CUs in a single DWO fileDavid Blaikie2017-05-201-6/+11
| | | | llvm-svn: 303482
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-1913-255/+536
| | | | | | | | | | | | 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
* Revert "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-1913-533/+255
| | | | | | | | | | | | | | | | | | 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
* Don't crash if someone tries to visit an empty type stream.Zachary Turner2017-05-191-0/+3
| | | | llvm-svn: 303408
* [CodeView] Reduce memory usage in TypeSerializer.Zachary Turner2017-05-191-5/+28
| | | | | | | | | | | We were using a BumpPtrAllocator to allocate stable storage for a record, then trying to insert that into a hash table. If a collision occurred, the bytes were never inserted and the allocation was unnecessary. At the cost of an extra hash computation, check first if it exists, and only if it does do we allocate and insert. llvm-svn: 303407
OpenPOWER on IntegriCloud