summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/CodeView/SymbolDumper.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-051-1/+1
| | | | | | assembly format for better readability llvm-svn: 367867
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-051-1/+1
| | | | | | | | 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-1/+1
| | | | | | assembly format for better readability llvm-svn: 367850
* Temporarily Revert "Changing representation of cv_def_range directives in ↵Eric Christopher2019-08-021-1/+1
| | | | | | | | | | 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-1/+1
| | | | | | assembly format for better readability llvm-svn: 367704
* [COFF, ARM64] Add CodeView register mappingTom Tan2019-05-311-8/+11
| | | | | | | | | | | | | | | | 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] Finish support for reading and writing S_ANNOTATION recordsReid Kleckner2019-05-151-0/+12
| | | | | | Implement dumping via llvm-pdbutil and llvm-readobj. llvm-svn: 360813
* [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
* 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
* Fix a compilation failure on non-MSVC compilers.Zachary Turner2018-10-081-1/+1
| | | | llvm-svn: 343952
* [PDB] Add the ability to lookup global symbols by name.Zachary Turner2018-10-081-1/+2
| | | | | | | | | | 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
* [codeview] Decode and dump FP regs from S_FRAMEPROC recordsReid Kleckner2018-09-111-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Minimal support for S_UNAMESPACE recordsAlexandre Ganea2018-07-311-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D50007 llvm-svn: 338417
* [CodeView] Initial support for emitting S_THUNK32 symbols for compiler...Brock Wyma2018-04-161-0/+1
| | | | | | | | | | | When emitting CodeView debug information, compiler-generated thunk routines should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so Visual Studio can properly step into the user code. This initial support only handles standard thunk ordinals. Differential Revision: https://reviews.llvm.org/D43838 llvm-svn: 330132
* Remove redundant includes from lib/DebugInfo.Michael Zolotukhin2017-12-131-1/+0
| | | | llvm-svn: 320620
* CodeView symbol dumper: use symbolic names for registersHans Wennborg2017-10-021-4/+7
| | | | | | https://reviews.llvm.org/D38469 llvm-svn: 314690
* [CodeView] Dump BuildInfoSym and ProcSym type indicesReid Kleckner2017-07-151-1/+1
| | | | | | | 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
* [codeview] Change readobj symbol dumping formatReid Kleckner2017-07-111-72/+19
| | | | | | | | Avoid duplicating DictScope with hand-written names everywhere. Print the S_-prefixed symbol kind for every record. This should make it easier to search for certain kinds of records when debugging PDB linking. llvm-svn: 307732
* [CodeView] Fix dumping of public symbol record flagsReid Kleckner2017-06-191-1/+1
| | | | | | | 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-4/+4
| | | | | | | | | 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-4/+4
| | | | | | | | | This reverts commit 83ea17ebf2106859a51fbc2a86031b44d33696ad. This is failing due to some strange template problems, so reverting until it can be straightened out. llvm-svn: 305505
* [llvm-pdbutil] rewrite the "raw" output style.Zachary Turner2017-06-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeView] Properly align symbol records on read/write.Zachary Turner2017-06-011-2/+2
| | | | | | | | | | | | | | | | | 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
* [CodeView] Move CodeView YAML code to ObjectYAML.Zachary Turner2017-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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] Add more DebugSubsection implementations.Zachary Turner2017-05-301-3/+3
| | | | | | | | This adds implementations for Symbols and FrameData, and renames the existing codeview::StringTable class to conform to the DebugSectionStringTable convention. llvm-svn: 304222
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-7/+6
| | | | | | | | | | | | 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-191-6/+7
| | | | | | | | | | | | | | | | | | 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
* [CodeView] Provide a common interface for type collections.Zachary Turner2017-05-181-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-readobj] Update readobj to re-use parsing code.Zachary Turner2017-05-031-12/+13
| | | | | | | | | | 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
* [PDB] It is not an error getting the "Invalid" Annotation opcode.Zachary Turner2017-03-171-2/+2
| | | | | | | The linker can insert invalid opcodes to indicate padding bytes, and we should not fail in this case. llvm-svn: 298016
* [CodeView] Finish decoupling TypeDatabase from TypeDumper.Zachary Turner2017-01-111-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the type dumper itself was passed around to a lot of different places and manipulated in ways that were more appropriate on the type database. For example, the entire TypeDumper was passed into the symbol dumper, when all the symbol dumper wanted to do was lookup the name of a TypeIndex so it could print it. That's what the TypeDatabase is for -- mapping type indices to names. Another example is how if the user runs llvm-pdbdump with the option to dump symbols but not types, we still have to visit all types so that we can print minimal information about the type of a symbol, but just without dumping full symbol records. The way we did this before is by hacking it up so that we run everything through the type dumper with a null printer, so that the output goes to /dev/null. But really, we don't need to dump anything, all we want to do is build the type database. Since TypeDatabaseVisitor now exists independently of TypeDumper, we can do this. We just build a custom visitor callback pipeline that includes a database visitor but not a dumper. All the hackery around printers etc goes away. After this patch, we could probably even delete the entire CVTypeDumper class since really all it is at this point is a thin wrapper that hides the details of how to build a useful visitation pipeline. It's not a priority though, so CVTypeDumper remains for now. After this patch we will be able to easily plug in a different style of type dumper by only implementing the proper visitation methods to dump one-line output and then sticking it on the pipeline. Differential Revision: https://reviews.llvm.org/D28524 llvm-svn: 291724
* [CodeView/PDB] Rename a bunch of files.Zachary Turner2017-01-111-1/+1
| | | | | | | | | | | We were starting to get some name clashes between llvm-pdbdump and the common CodeView framework, so I took this opportunity to rename a bunch of files to more accurately describe their usage. This also helps in llvm-pdbdump to distinguish between different files and whether they are used for pretty dump mode or raw dump mode. llvm-svn: 291627
* Resubmit "[CodeView] Hook CodeViewRecordIO for reading/writing symbols."Zachary Turner2016-12-161-145/+131
| | | | | | | The original patch was broken due to some undefined behavior as well as warnings that were triggering -Werror. llvm-svn: 290000
* Revert "[CodeView] Hook CodeViewRecordIO for reading/writing symbols."Zachary Turner2016-12-161-131/+145
| | | | | | | This reverts commit r289978, which is failing due to some rebase/merge issues. llvm-svn: 289981
* [CodeView] Hook CodeViewRecordIO for reading/writing symbols.Zachary Turner2016-12-161-145/+131
| | | | | | | | | This is the 3rd of 3 patches to get reading and writing of CodeView symbol and type records to use a single codepath. Differential Revision: https://reviews.llvm.org/D26427 llvm-svn: 289978
* Refactor Symbol visitor code.Zachary Turner2016-10-071-93/+149
| | | | | | | | | | | | | Type visitor code had already been refactored previously to decouple the visitor and the visitor callback interface. This was necessary for having the flexibility to visit in different ways (for example, dumping to yaml, reading from yaml, dumping to ScopedPrinter, etc). This patch merely implements the same visitation pattern for symbol records that has already been implemented for type records. llvm-svn: 283609
* [CodeView] Emit an appropriate symbol kind for globalsDavid Majnemer2016-07-061-0/+2
| | | | | | | We emitted debug info for globals/functions as if they all had external linkage. Instead, emit local symbol records when appropriate. llvm-svn: 274676
* [codeview] Use one byte for S_FRAMECOOKIE CookieKind and add flags byteReid Kleckner2016-06-241-0/+1
| | | | | | | | | | We bailed out while printing codeview for an MSVC compiled SemaExprCXX.cpp that used this record. The MS reference headers look incorrect here, which is probably why we had this bug. They use a 32-bit enum as the field type, but the actual record appears to use one byte for the cookie kind followed by a flags byte. llvm-svn: 273691
* [pdb] Parse and dump section map and section contribsZachary Turner2016-06-021-266/+25
| | | | | | | Differential Revision: http://reviews.llvm.org/D20876 Reviewed By: rnk, ruiu llvm-svn: 271488
* [SymbolDumper] Validate the string table offset before using itDavid Majnemer2016-05-281-6/+6
| | | | llvm-svn: 271145
* [SymbolDumper] Validate the string table offset before using itDavid Majnemer2016-05-281-5/+6
| | | | llvm-svn: 271142
* [pdb] Finish conversion to zero copy pdb access.Zachary Turner2016-05-281-2/+2
| | | | | | | | | | | | | | This converts remaining uses of ByteStream, which was still left in the symbol stream and type stream, to using the new StreamInterface zero-copy classes. RecordIterator is finally deleted, so this is the only way left now. Additionally, more error checking is added when iterating the various streams. With this, the transition to zero copy pdb access is complete. llvm-svn: 271101
* Resubmit "[pdb] Allow zero-copy read support for symbol streams.""Zachary Turner2016-05-271-1/+1
| | | | | | | | | Due to differences in template instantiation rules, it is not portable to static_assert(false) inside of an invalid specialization of a template. Instead I just =delete the method so that it can't be used, and leave a comment that it must be explicitly specialized. llvm-svn: 271027
* Revert "[pdb] Allow zero-copy read support for symbol streams."Chad Rosier2016-05-271-1/+1
| | | | | | | | This reverts commit r271024 due to error: static_assert failed "You must either provide a specialization of VarStreamArrayExtractor or a custom extractor" llvm-svn: 271026
* [pdb] Allow zero-copy read support for symbol streams.Zachary Turner2016-05-271-1/+1
| | | | | | | | | | This reduces the amount of memory used by llvm-pdbdump by roughly 1/3 of the size of the PDB file. Differential Revision: http://reviews.llvm.org/D20724 Reviewed By: ruiu llvm-svn: 271025
* [codeview] Add support for S_EXPORT symbol.Zachary Turner2016-05-251-0/+16
| | | | llvm-svn: 270636
* [codeview] Add support for new type records.Zachary Turner2016-05-241-1/+182
| | | | | | | | | | | | | | | | | | | This adds support for parsing and dumping the following symbol types: S_LPROCREF S_ENVBLOCK S_COMPILE2 S_REGISTER S_COFFGROUP S_SECTION S_THUNK32 S_TRAMPOLINE As of this patch, the test PDB files no longer have any unknown symbol types. llvm-svn: 270628
* [codeview, pdb] Dump symbol records in publics streamZachary Turner2016-05-241-0/+17
| | | | | | | Differential Revision: http://reviews.llvm.org/D20580 Reviewed By: ruiu llvm-svn: 270597
* Fix build errorsZachary Turner2016-05-241-2/+2
| | | | llvm-svn: 270587
* Dump symbol record details in llvm-pdbdumpZachary Turner2016-05-241-4/+4
| | | | | | | | | | | | | This makes use of the newly introduced `CVSymbolVisitor` to dump details of each type of symbol record in the symbol streams. Future patches will bring this visitor based dumping to the publics stream, as well as creating a `SymbolDumpDelegate` to print more information about relocations etc. Differential Revision: http://reviews.llvm.org/D20545 Reviewed By: ruiu llvm-svn: 270585
OpenPOWER on IntegriCloud