summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-pdbutil/MinimalSymbolDumper.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+3
| | | | | | assembly format for better readability llvm-svn: 367867
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-051-3/+2
| | | | | | | | debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. llvm-svn: 367861
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-2/+3
| | | | | | assembly format for better readability llvm-svn: 367850
* Temporarily Revert "Changing representation of cv_def_range directives in ↵Eric Christopher2019-08-021-3/+2
| | | | | | | | | | Codeview debug info assembly format for better readability" This is breaking bots and the author asked me to revert. This reverts commit 367704. llvm-svn: 367707
* Changing representation of cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-021-2/+3
| | | | | | assembly format for better readability llvm-svn: 367704
* [COFF, ARM64] Add CodeView register mappingTom Tan2019-05-311-17/+37
| | | | | | | | | | | | | | | | CodeView has its own register map which is defined in cvconst.h. Missing this mapping before saving register to CodeView causes debugger to show incorrect value for all register based variables, like variables in register and local variables addressed by register (stack pointer + offset). This change added mapping between LLVM register and CodeView register so the correct register number will be stored to CodeView/PDB, it aso fixed the mapping from CodeView register number to register name based on current CPUType but print PDB to yaml still assumes X86 CPU and needs to be fixed. Differential Revision: https://reviews.llvm.org/D62608 llvm-svn: 362280
* [codeview] Revert inline line table change of r362264Reid Kleckner2019-05-311-0/+4
| | | | | | | | | | | | Testing with debuggers shows that our previous behavior was correct. The reason I thought MSVC did things differently is that MSVC prefers to use the 0xB combined code offset and code length update opcode when inline sites are discontiguous. Keep the test changes, and update the llvm-pdbutil inline line table dumper to account for this new interpretation of the opcodes. llvm-svn: 362277
* [llvm-pdbutil] Dump inline call site line table annotationsReid Kleckner2019-05-291-5/+77
| | | | | | | | | This ports and improves on some existing llvm-readobj -codeview dumping functionality that llvm-pdbutil lacked. Helpful for comparing inline line tables between MSVC and clang. llvm-svn: 362037
* [codeview] Finish support for reading and writing S_ANNOTATION recordsReid Kleckner2019-05-151-0/+9
| | | | | | Implement dumping via llvm-pdbutil and llvm-readobj. llvm-svn: 360813
* [codeview] Remove Type member from CVRecordReid Kleckner2019-04-041-1/+1
| | | | | | | | | | | | | | | | | 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
* Add Swift enumerator value for CodeView::SourceLanguageNathan Lanza2019-03-111-0/+1
| | | | | | | | | | | | | | | Summary: Swift now generates PDBs for debugging on Windows. llvm and lldb need a language enumerator value too properly handle the output emitted by swiftc. Subscribers: jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59231 llvm-svn: 355882
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* 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-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [codeview] Improve readobj FPO dumper and pdbutil register namesReid Kleckner2018-09-071-8/+17
| | | | | | The improved dumping helps me investigate PR38857. llvm-svn: 341695
* [CodeView] Minimal support for S_UNAMESPACE recordsAlexandre Ganea2018-07-311-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D50007 llvm-svn: 338417
* [PDB] Correctly link S_FILESTATIC records.Zachary Turner2018-01-051-0/+13
| | | | | | | | | | | | | | | | | This is not a record type that clang currently generates, but it is a record that is encountered in object files generated by cl. This record is unusual in that it refers directly to the string table instead of indirectly to the string table via the FileChecksums table. Because of this, it was previously overlooked and we weren't remapping the string indices at all. This would lead to crashes in MSVC when trying to display a variable whose debug info involved an S_FILESTATIC. Original bug report by Alexander Ganea Differential Revision: https://reviews.llvm.org/D41718 llvm-svn: 321883
* Don't crash in llvm-pdbutil when dumping TypeIndexes with high bit set.Zachary Turner2017-12-151-1/+1
| | | | | | | | | This is a special code that indicates that it's a function id. While I'm still not certain how to interpret these, we definitely should *not* be using these values as indices into an array directly. For now, when we encounter one of these, just print the numeric value. llvm-svn: 320775
* [codeview] Fix handling of S_HEAPALLOCSITEReid Kleckner2017-10-241-1/+1
| | | | | | | | | | The type index is from the TPI stream, not the IPI stream. Fix the dumper, fix type index discovery, and add a test in LLD. Also improve the log message we emit when we fail to rewrite type indices in LLD. That's how I found this bug. llvm-svn: 316461
* Fix -Wcovered-switch-default warnings from r314821Hans Wennborg2017-10-031-2/+1
| | | | llvm-svn: 314826
* CodeView: Provide a .def file with the register idsHans Wennborg2017-10-031-50/+5
| | | | | | | | | | | | | | The list of register ids was previously written out in a couple of dirrent places. This puts it in a .def file and also adds a few more registers (e.g. the x87 regs) which should lead to more readable dumps, but I didn't include the whole list since that seems unnecessary. X86_MC::initLLVMToSEHAndCVRegMapping is pretty ugly, but at least it's not relying on magic constants anymore. The TODO of using tablegen still stands. Differential revision: https://reviews.llvm.org/D38480 llvm-svn: 314821
* [llvm-pdbutil] Add support for dumping detailed module stats.Zachary Turner2017-08-211-12/+1
| | | | | | | | | | | | | | | This adds support for dumping a summary of module symbols and CodeView debug chunks. This option prints a table for each module of all of the symbols that occurred in the module and the number of times it occurred and total byte size. Then at the end it prints the totals for the entire file. Additionally, this patch adds the -jmc (just my code) option, which suppresses modules which are from external libraries or linker imports, so that you can focus only on the object files and libraries that originate from your own source code. llvm-svn: 311338
* Remove useless default case in switchVictor Leschuk2017-08-181-3/+0
| | | | llvm-svn: 311149
* Fix warning about covered switch default.Zachary Turner2017-08-171-1/+1
| | | | llvm-svn: 311129
* [llvm-pdbutil] Fix some dumping issues.Zachary Turner2017-08-171-6/+7
| | | | | | | | | | | | | | | | | When dumping, we were treating the S_INLINESITESYM as referring to a type record, when it actually refers to an id record. We had this correct in TypeIndexDiscovery, so our merging algorithm should be fine, but we had it wrong in the dumper, which means it would appear to work most of the time, unless the index was out of bounds in the type stream, when it would fail. Fixed this, and audited a few other cases to make them match the behavior in TypeIndexDiscovery. Also, I've now observed a new symbol record with kind 0x1168 which I have no clue what it is, so to avoid crashing we have to just print "Unknown Symbol Kind". llvm-svn: 311117
* Fix a few minor issues when dumping symbols.Zachary Turner2017-08-171-0/+5
| | | | | | | | | | | | 1) We weren't handling symbol types that weren't able to parse, even if we knew what the leaf type was. This was triggering when trying to dump /DEBUG:FASTLINK PDBs, where we expect a certain symbol to show up, but we just don't know how to parse it. 2) We lost the code for dumping record bytes, so this was added back. llvm-svn: 311116
* Output S_SECTION symbols to the Linker module.Zachary Turner2017-08-111-5/+14
| | | | | | | | | | | | | | PDBs need to contain 1 module for each object file/compiland, and a special one synthesized by the linker. This one contains a symbol record for each output section in the executable with its address information. This patch adds such symbols to the linker module. Note that we also are supposed to add an S_COFFGROUP symbol for what appears to be each input section that contributes to each output section, but it's not entirely clear how to generate these yet, so I'm leaving that for a separate patch. llvm-svn: 310754
* [PDB] Fix linking of function symbols and local variables.Zachary Turner2017-08-081-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | The compiler outputs PROC32_ID symbols into the object files for functions, and these symbols have an embedded type index which, when copied to the PDB, refer to the IPI stream. However, the symbols themselves are also converted into regular symbols (e.g. S_GPROC32_ID -> S_GPROC32), and type indices in the regular symbol records refer to the TPI stream. So this patch applies two fixes to function records. 1. It converts ID symbols to the proper non-ID record type. 2. After remapping the type index from the object file's index space to the PDB file/IPI stream's index space, it then remaps that index to the TPI stream's index space by. Besides functions, during the remapping process we were also discarding symbol record types which we did not recognize. In particular, we were discarding S_BPREL32 records, which is what MSVC uses to describe local variables on the stack. So this patch fixes that as well by copying them to the PDB. Differential Revision: https://reviews.llvm.org/D36426 llvm-svn: 310394
* [codeview] Emit 'D' as the cv source language for D codeReid Kleckner2017-07-241-0/+1
| | | | | | | | | This matches DMD: https://github.com/dlang/dmd/blob/522263965cf3a27ed16b31f3c3562db86cdeabec/src/ddmd/backend/cv8.c#L199 Fixes PR33899. llvm-svn: 308890
* [COFF, ARM64, CodeView] Add support to emit CodeView debug info for ARM64 COFFMandeep Singh Grang2017-07-201-0/+1
| | | | | | | | | | | | Reviewers: compnerd, ruiu, rnk, zturner Reviewed By: rnk Subscribers: majnemer, aemerson, aprantl, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D35518 llvm-svn: 308665
* [CodeView] Dump BuildInfoSym and ProcSym type indicesReid Kleckner2017-07-151-2/+3
| | | | | | | I need to print the type index in hex so that I can match it in FileCheck for a test I'm writing. llvm-svn: 308107
* Remove spurious semicolons.Zachary Turner2017-06-301-34/+0
| | | | llvm-svn: 306891
* [llvm-pdbutil] Output the symbol offset when dumping.Zachary Turner2017-06-301-44/+86
| | | | | | | | | | | | | | | | Type records have a unique type index, but symbol records do not. Instead, symbol records refer to other symbol records by referencing their offset in the symbol stream. In a sense this is the analogue of the TypeIndex, but we are not printing it in the dumper. Printing it not only gives us more useful information when manually investigating the contents of a PDB, but also allows us to write better tests by enabling us to verify that fields that reference other symbol records do so correctly. Differential Revision: https://reviews.llvm.org/D34906 llvm-svn: 306890
* [CodeView] Fix dumping of public symbol record flagsReid Kleckner2017-06-191-1/+15
| | | | | | | I noticed nonsensical type information while dumping PDBs produced by MSVC. llvm-svn: 305708
* Resubmit "[llvm-pdbutil] rewrite the "raw" output style."Zachary Turner2017-06-151-0/+749
| | | | | | | | | This resubmits commit c0c249e9f2ef83e1d1e5f166b50673d92f3579d7. It was broken due to some weird template issues, which have since been fixed. llvm-svn: 305517
* Revert "[llvm-pdbutil] rewrite the "raw" output style."Zachary Turner2017-06-151-749/+0
| | | | | | | | | This reverts commit 83ea17ebf2106859a51fbc2a86031b44d33696ad. This is failing due to some strange template problems, so reverting until it can be straightened out. llvm-svn: 305505
* Fix some more warnings.Zachary Turner2017-06-151-10/+6
| | | | llvm-svn: 305499
* [llvm-pdbutil] rewrite the "raw" output style.Zachary Turner2017-06-151-0/+753
After some internal discussions, we agreed that the raw output style had outlived its usefulness. It was originally created before we had even thought of dumping to YAML, and it was intended to give us some insight into the internals of a PDB file. Now we have YAML mode which does almost exactly this but is more powerful in that it can round-trip back to a PDB, which the raw mode could not do. So the raw mode had become purely a maintenance burden. One option was to just delete it. However, its original goal was to be as readable as possible while staying close to the "metal" - i.e. presenting the output in a way that maps directly to the underlying file format. We don't actually need that last requirement anymore since it's covered by the yaml mode, so we could repurpose "raw" mode to actually just be as readable as possible. This patch implements about 80% of the functionality previously in raw mode, but in a completely different style that is more akin to what cvdump outputs. Records are very compressed, often times appearing on just one line. One nice thing about this is that it makes full record matching easier, because you can grep for indices, names, and leaf types on a single line often. See the tests for some examples of what the new output looks like. Note that this patch actually regresses the functionality of raw mode in a few areas, but only because the patch was already unreasonably large and going 100% would have been even worse. Specifically, this patch is missing: The ability to dump module debug subsections (checksums, lines, etc) The ability to dump section headers Aside from that everything is here. While goign through the tests fixing them all up, I found many duplicate tests. They've been deleted. In subsequent patches I will go through and re-add the missing functionality. Differential Revision: https://reviews.llvm.org/D34191 llvm-svn: 305495
OpenPOWER on IntegriCloud