summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/PDB/Native
Commit message (Collapse)AuthorAgeFilesLines
* [CodeView] Align type records on 4-bytes when emitting PDBsAlexandre Ganea2020-04-161-2/+8
| | | | | | | | | | | | | | | When emitting PDBs, the TypeStreamMerger class is used to merge .debug$T records from the input .OBJ files into the output .PDB stream. Records in .OBJs are not required to be aligned on 4-bytes, and "The Netwide Assembler 2.14" generates non-aligned records. When compiling with -DLLVM_ENABLE_ASSERTIONS=ON, an assert was triggered in MergingTypeTableBuilder when non-ghash merging was used. With ghash merging there was no assert. As a result, LLD could potentially generate a non-aligned TPI stream. We now align records on 4-bytes when record indices are remapped, in TypeStreamMerger::remapIndices(). Differential Revision: https://reviews.llvm.org/D75081 (cherry picked from commit a7325298e1f311b383b8ce5ba8e2d3698fef472a)
* [pdbutil] Fixed -Wdeprecated-copy in DbiModuleDescriptorDávid Bolvanský2019-11-231-5/+0
|
* [PDB] Make pdb::DbiModuleDescriptor destructor trivialFangrui Song2019-11-111-2/+0
|
* [LLVMDebugInfoPDB] - Use cantFail() instead of assert().George Rimar2019-10-221-12/+13
| | | | | | | | | | | | | | | | Currently injected-sources-native.test fails with "Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed)" when llvm is compiled with LLVM_ENABLE_ABI_BREAKING_CHECKS in Release. The problem is that getStringForID returns Expected<StringRef> and Expected value must always be checked, even if it is in success state. Checking with assert only helps in Debug and is wrong. Differential revision: https://reviews.llvm.org/D69251 llvm-svn: 375492
* Unify the two CRC implementationsHans Wennborg2019-10-093-10/+6
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1512-46/+46
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* llvm-pdbdump: Fix several smaller issues with injected source compression ↵Nico Weber2019-07-171-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | handling - getCompression() used to return a PDB_SourceCompression even though the docs for IDiaInjectedSource are explicit about the return value being compiler-dependent. Return an uint32_t instead, and make the printing code handle unknown values better by printing "Unknown" and the int value instead of not printing any compression. - Print compressed contents as hex dump, not as string. - Add compression type "DotNet", which is used (at least) by csc.exe, the C# compiler. Also add a lengthy comment describing the stream contents (derived from looking at the raw hex contents long enough to see the GUIDs, which led me to the roslyn and mono implementations for handling this). - The native injected source dumper was dumping the contents of the whole data stream -- but csc.exe writes a stream that's padded with zero bytes to the next 512 boundary, and the dia api doesn't display those padding bytes. So make NativeInjectedSource::getCode() do the same thing. Differential Revision: https://reviews.llvm.org/D64879 llvm-svn: 366386
* Teach `llvm-pdbutil pretty -native` about `-injected-sources`Nico Weber2019-07-164-11/+245
| | | | | | | | | `pretty -native -injected-sources -injected-source-content` works with this patch, and produces identical output to the dia version. Differential Revision: https://reviews.llvm.org/D64428 llvm-svn: 366236
* Expand comment about how StringsToBuckets was computed, and add more entriesNico Weber2019-07-151-1/+14
| | | | | | | | | | | | | | | | | The construction was explained in https://reviews.llvm.org/D44810?id=139526#inline-391999 but reading the code shouldn't require hunting down old reviews to understand it. The precomputed list was missing an entry for the empty list case, and one entry at the very end. (The current last entry is the last one where 3 * BucketCount fits in a signed int, but the reference implementation uses unsigneds as far as I can tell, so there's room for one more entry.) No behavior change for inputs seen in practice. Differential Revision: https://reviews.llvm.org/D64738 llvm-svn: 366107
* PDB HashTable: Move TraitsT from class parameter to the methods that need itNico Weber2019-07-122-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | The traits object is only used by a few methods. Deserializing a hash table and walking it is possible without the traits object, so it shouldn't be required to build a dummy object for that use case. The TraitsT object used to be a function template parameter before r327647, this restores it to that state. This makes it clear that the traits object isn't needed at all in 1 of the current 3 uses of HashTable (and I am going to add another use that doesn't need it), and that the default PdbHashTraits isn't used outside of tests. While here, also re-enable 3 checks in the test that were commented out (which requires making HashTableInternals templated and giving FooBar an operator==). No intended behavior change. Differential Revision: https://reviews.llvm.org/D64640 llvm-svn: 365974
* Slightly simplify MappedBlockStream::createIndexedStream() callsNico Weber2019-07-123-31/+23
| | | | | | | | | | | | | | | | All callers had a PDBFile object at hand, so call Pdb.createIndexedStream() instead, which pre-populates all the arguments (and returns nullptr for kInvalidStreamIndex). Also change safelyCreateIndexedStream() to only take the string index, and update callers. Make the method public and call it in two places that manually did the bounds checking before. No intended behavior change. Differential Revision: https://reviews.llvm.org/D64633 llvm-svn: 365936
* Deduplicate S_CONSTANTs in LLD.Amy Huang2019-06-111-4/+4
| | | | | | | | | | | | | | Summary: Deduplicate S_CONSTANTS when linking, if they have the same value. Reviewers: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63151 llvm-svn: 363089
* [PDB] Fix hash function used to write /src/headerblockNico Weber2019-04-292-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | lld-link used to write PDB files that DIA couldn't recover natvis files from if: - The global strings table was > 64kiB - There were at least 3 natvis files The cause was that the hash function for the /src/headerblock stream was incorrect: It needs to be truncated to 16 bit. If the global strings table was <= 64kiB, truncating to 16 bit is a no-op, so this wasn't needed for small programs. If there are only 1 or 2 natvis files, then the growth strategy in HashTable::grow() would mean the hash table would have 2 buckets (for 1 natvis file) or 4 buckets (for 4 natvis files), and since the hash function is used modulo number of buckets, and since 2 and 4 divide 0x10000, the missing `% 0x10000` is a no-op there too. For 3 natvis files, the hash table grows to 6 buckets, which has a factor that's not common with 0x10000 and the difference starts to matter. Fixes PR41626. Differential Revision: https://reviews.llvm.org/D61277 llvm-svn: 359515
* Use llvm::stable_sortFangrui Song2019-04-231-2/+1
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* [codeview] Remove Type member from CVRecordReid Kleckner2019-04-041-2/+2
| | | | | | | | | | | | | | | | | Summary: Now CVType and CVSymbol are effectively type-safe wrappers around ArrayRef<uint8_t>. Make the kind() accessor load it from the RecordPrefix, which is the same for types and symbols. Reviewers: zturner, aganea Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60018 llvm-svn: 357658
* Delay initialization of three static global maps, NFCReid Kleckner2019-03-281-56/+55
| | | | | | | This avoids allocating a few KB of heap memory on startup, and instead allocates these maps lazily. I noticed this while profiling LLD. llvm-svn: 357192
* [DebugInfo][PDB] Don't write empty debug streamsAlexandre Ganea2019-03-182-6/+16
| | | | | | | | | | | Before, empty debug streams were written as 8 bytes (4 bytes signature + 4 bytes for the GlobalRefs count). With this patch, unused empty streams aren't emitted anymore. Modules now encode 65535 as an 'unused stream' value, by convention. Also fix the * Linker * contrib section which wasn't correctly emitted previously. Differential Revision: https://reviews.llvm.org/D59502 llvm-svn: 356395
* Move some classes into anonymous namespaces. NFC.Benjamin Kramer2019-02-111-0/+2
| | | | llvm-svn: 353710
* [CodeView] Fix cycles in debug info when merging Types with global hashes Alexandre Ganea2019-02-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When type streams with forward references were merged using GHashes, cycles were introduced in the debug info. This was caused by GlobalTypeTableBuilder::insertRecordAs() not inserting the record on the second pass, thus yielding an empty ArrayRef at that record slot. Later on, upon PDB emission, TpiStreamBuilder::commit() would skip that empty record, thus offseting all indices that came after in the stream. This solution comes in two steps: 1. Fix the hash calculation, by doing a multiple-step resolution, iff there are forward references in the input stream. 2. Fix merge by resolving with multiple passes, therefore moving records with forward references at the end of the stream. This patch also adds support for llvm-readoj --codeview-ghash. Finally, fix dumpCodeViewMergedTypes() which previously could reference deleted memory. Fixes PR40221 Differential Revision: https://reviews.llvm.org/D57790 llvm-svn: 353412
* [NativePDB] Fix access to both old & new fpo data entries from dbi streamAleksandr Urakov2019-01-301-36/+69
| | | | | | | | | | | | | | | | | | Summary: This patch fixes access to fpo streams in native pdb from DbiStream and makes code consistent with DbiStreamBuilder. Patch By: leonid.mashinskiy Reviewers: zturner, aleksandr.urakov Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56725 llvm-svn: 352615
* [PDB] Increase TPI hash bucket count.Zachary Turner2019-01-241-2/+2
| | | | | | | | | | | | | | | PDBs contain several serialized hash tables. In the microsoft-pdb repo published to support LLVM implementing PDB support, the provided initializes the bucket count for the TPI and IPI streams to the maximum size. This occurs in tpi.cpp L33 and tpi.cpp L398. In the LLVM code for generating PDBs, these streams are created with minimum number of buckets. This difference makes LLVM generated PDBs slower for when used for debugging. Patch by C.J. Hebert Differential Revision: https://reviews.llvm.org/D56942 llvm-svn: 352117
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1937-148/+111
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [PDB] Add some helper functions for working with scopes.Zachary Turner2018-12-171-0/+7
| | | | llvm-svn: 349361
* Support skewed stream arrays.Zachary Turner2018-12-061-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VarStreamArray was built on the assumption that it is backed by a StreamRef, and offset 0 of that StreamRef is the first byte of the first record in the array. This is a logical and intuitive assumption, but unfortunately we have use cases where it doesn't hold. Specifically, a PDB module's symbol stream is prefixed by 4 bytes containing a magic value, and the first byte of record data in the array is actually at offset 4 of this byte sequence. Previously, we would just truncate the first 4 bytes and then construct the VarStreamArray with the resulting StreamRef, so that offset 0 of the underlying stream did correspond to the first byte of the first record, but this is problematic, because symbol records reference other symbol records by the absolute offset including that initial magic 4 bytes. So if another record wants to refer to the first record in the array, it would say "the record at offset 4". This led to extremely confusing hacks and semantics in loading code, and after spending 30 minutes trying to get some math right and failing, I decided to fix this in the underlying implementation of VarStreamArray. Now, we can say that a stream is skewed by a particular amount. This way, when we access a record by absolute offset, we can use the same values that the records themselves contain, instead of having to do fixups. Differential Revision: https://reviews.llvm.org/D55344 llvm-svn: 348499
* [PDB] Emit S_UDT records in LLD.Zachary Turner2018-12-041-7/+32
| | | | | | | | | | | Previously these were dropped. We now understand them sufficiently well to start emitting them. From the debugger's perspective, this now enables us to have debug info about typedefs (both global and function-locally scoped) Differential Revision: https://reviews.llvm.org/D55228 llvm-svn: 348306
* Fix issue with Tpi Stream hash map.Zachary Turner2018-12-031-0/+6
| | | | | | | | Part of the patch to not build the hash map eagerly was omitted due to a merge conflict. Add it back, which should fix the failing tests. llvm-svn: 348166
* Don't build the Tpi Hash map by default.Zachary Turner2018-12-031-3/+0
| | | | | | | This is very slow and should be done for specific cases where lookups will need to happen. llvm-svn: 348160
* Add missing error checking code intended for r347687Reid Kleckner2018-11-271-2/+4
| | | | llvm-svn: 347690
* [PDB] Add symbol records in bulkReid Kleckner2018-11-271-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from 12.9s to 9.8s. Symbol records are typically small (16.7 bytes on average), but we processed them one at a time. CVSymbol is a relatively "large" type. It wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we don't need. Before this change, each DbiModuleDescriptorBuilder would maintain an array of CVSymbols, and would write them individually with a BinaryItemStream. With this change, we now add symbols that happen to appear contiguously in bulk. For each .debug$S section (roughly one per function), we allocate two copies, one for relocation, and one for realignment purposes. For runs of symbols that go in the module stream, which is most symbols, we now add them as a single ArrayRef<uint8_t>, so the vector DbiModuleDescriptorBuilder is roughly linear in the number of .debug$S sections (O(# funcs)) instead of the number of symbol records (very large). Some stats on symbol sizes for the curious: PDB size: 507M sym bytes: 316,508,016 sym count: 18,954,971 sym byte avg: 16.7 As future work, we may be able to skip copying symbol records in the linker for realignment purposes if we make LLVM write them aligned into the object file. We need to double check that such symbol records are still compatible with link.exe, but if so, it's definitely worth doing, since my profile shows we spend 500ms in memcpy in the symbol merging code. We could potentially cut that in half by saving a copy. Alternatively, we could apply the relocations *after* we iterate the symbols. This would require some careful re-engineering of the relocation processing code, though. Reviewers: zturner, aganea, ruiu Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54554 llvm-svn: 347687
* [NativePDB] Improved support for nested type reconstruction.Zachary Turner2018-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a previous patch, we pre-processed the TPI stream in order to build the reverse mapping from nested type -> parent type so that we could accurately reconstruct a DeclContext hierarchy. However, there were some issues. An LF_NESTTYPE record is really just a typedef, so although it happens to be used to indicate the name of the nested type and referring to the global record which defines the type, it is also used for every other kind of nested typedef. When we rebuild the DeclContext hierarchy, we want it to be as accurate as possible, which means that if we have something like: struct A { struct B {}; using C = B; }; We don't want to create two CXXRecordDecls in the AST each with the exact same definition. We just want to create one for B and then define C as an alias to B. Previously, however, it would not be able to distinguish between the two cases and it would treat A::B and A::C as being two classes each with separate definitions. We address the first half of improving the pre-processing logic so that only actual definitions are treated this way. Later, in a followup patch, we can handle the case of nested typedefs since we're already going to be enumerating the field list anyway and this patch introduces the general framework for distinguishing between the two cases. Differential Revision: https://reviews.llvm.org/D54357 llvm-svn: 346786
* Revert "Revert "[PDB] Extend IPDBSession's interface to retrieve frame data""Aleksandr Urakov2018-10-231-0/+5
| | | | | | This reverts commit 466ce67d6ec444962e5cc0136243c16a453190c0. llvm-svn: 345010
* Some cleanups to the native pdb plugin [NFC].Zachary Turner2018-10-221-0/+19
| | | | | | | | | | | This is mostly some cleanup done in the process of implementing some basic support for types. I tried to split up the patch a bit to get some of the NFC portion of the patch out into a separate commit, and this is the result of that. It moves some code around, deletes some spurious namespace qualifications, removes some unnecessary header includes, forward declarations, etc. llvm-svn: 344913
* Revert "[PDB] Extend IPDBSession's interface to retrieve frame data"Aleksandr Urakov2018-10-221-5/+0
| | | | | | This reverts commit b5c7e2f9a4dbb34e3667c4bb4972735eadd3247a. llvm-svn: 344909
* [PDB] Extend IPDBSession's interface to retrieve frame dataAleksandr Urakov2018-10-221-0/+5
| | | | | | | | | | | | | | | | | | Summary: This patch just extends the `IPDBSession` interface to allow retrieving of frame data through it, and adds an implementation over DIA. It is needed for an implementation (for now with DIA) of the conversion from FPO programs to DWARF expressions mentioned in D53086. Reviewers: zturner, asmith, rnk Reviewed By: asmith Subscribers: mgorny, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D53324 llvm-svn: 344886
* [PDB] Fix another bug in globals stream name lookup.Zachary Turner2018-10-091-9/+15
| | | | | | | | When we're on the last bucket the computation is tricky. We were failing when the last bucket contained multiple matches. Added a new test for this. llvm-svn: 344081
* [PDB] Fix failure on big endian machines.Zachary Turner2018-10-091-1/+2
| | | | | | | | | | | | | | | We changed an ArrayRef<uint8_t> to an ArrayRef<uint32_t>, but it needs to be an ArrayRef<support::ulittle32_t>. We also change ArrayRef<> to FixedStreamArray<>. Technically an ArrayRef<> will work, but it can cause a copy in the underlying implementation if the memory is not contiguous, and there's no reason not to use a FixedStreamArray<>. Thanks to nemanjai@ and thakis@ for helping me track this down and confirm the fix. llvm-svn: 344063
* Remove unused variable.Zachary Turner2018-10-081-1/+0
| | | | llvm-svn: 344002
* [PDB] fix a bug in global stream name lookup.Zachary Turner2018-10-081-5/+8
| | | | | | | When we're looking up a record in the last hash bucket chain, we need to be careful with the end-offset calculation. llvm-svn: 344001
* [DebugInfo][PDB] Fix a signed/unsigned coversion warningKristina Brooks2018-10-081-1/+1
| | | | | | | | | | | | Fix the following warning when compiling with clang (caused by commit rL343951): GlobalsStream.cpp:61:33: warning: comparison of integers of different signs: 'int' and 'uint32_t' This also avoids double evaluation of `GlobalsTable.HashBuckets.size()`. llvm-svn: 343957
* Fix a -Wsign-compare warning.Zachary Turner2018-10-081-1/+1
| | | | llvm-svn: 343953
* [PDB] Add the ability to lookup global symbols by name.Zachary Turner2018-10-083-6/+63
| | | | | | | | | | The Globals table is a hash table keyed on symbol name, so it's possible to lookup symbols by name in O(1) time. Add a function to the globals stream to do this, and add an option to llvm-pdbutil to exercise this, then use it to write some tests to verify correctness. llvm-svn: 343951
* [PDB] Add support for dumping Typedef records.Zachary Turner2018-10-014-0/+121
| | | | | | | | | | These work a little differently because they are actually in the globals stream and are treated as symbol records, even though DIA presents them as types. So this also adds the necessary infrastructure to cache records that live somewhere other than the TPI stream as well. llvm-svn: 343507
* [PDB] Add support for parsing VFTable Shape records.Zachary Turner2018-10-014-2/+52
| | | | | | This allows them to be returned from the native API. llvm-svn: 343506
* [PDB] Add native support for dumping array types.Zachary Turner2018-09-303-0/+74
| | | | llvm-svn: 343412
* [PDB] Better native API support for pointers.Zachary Turner2018-09-291-0/+59
| | | | | | | | | | | | We didn't properly detect when a pointer was a member pointer, and when that was the case we were not properly returning class parent info. This caused member pointers to render incorrectly in pretty mode. However, we didn't even have pretty tests for pointers in native mode, so those are also added now to ensure this. llvm-svn: 343393
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-5/+4
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* Add missing include.Zachary Turner2018-09-211-0/+1
| | | | llvm-svn: 342781
* [NativePDB] Add support for reading function signatures.Zachary Turner2018-09-215-29/+246
| | | | | | | This adds support for parsing function signature records and returning them through the native DIA interface. llvm-svn: 342780
* [PDB] Add native reading support for UDT / class types.Zachary Turner2018-09-217-131/+376
| | | | | | | | | | | | This allows the native reader to find records of class/struct/ union type and dump them. This behavior is tested by using the diadump subcommand against golden output produced by actual DIA SDK on the same PDB file, and again using pretty -native to confirm that we actually dump the classes. We don't find class members or anything like that yet, for now it's just the class itself. llvm-svn: 342779
* Fix warnings.Zachary Turner2018-09-201-1/+0
| | | | llvm-svn: 342670
OpenPOWER on IntegriCloud