summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-readobj/COFFDumper.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLD] Implement /guard:[no]longjmpReid Kleckner2018-02-131-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This protects calls to longjmp from transferring control to arbitrary program points. Instead, longjmp calls are limited to the set of registered setjmp return addresses. This also implements /guard:nolongjmp to allow users to link in object files that call setjmp that weren't compiled with /guard:cf. In this case, the linker will approximate the set of address taken functions, but it will leave longjmp unprotected. I used the following program to test, compiling it with different -guard flags: $ cl -c t.c -guard:cf $ lld-link t.obj -guard:cf #include <setjmp.h> #include <stdio.h> jmp_buf buf; void g() { printf("before longjmp\n"); fflush(stdout); longjmp(buf, 1); } void f() { if (setjmp(buf)) { printf("setjmp returned non-zero\n"); return; } g(); } int main() { f(); printf("hello world\n"); } In particular, the program aborts when the code is compiled *without* -guard:cf and linked with -guard:cf. That indicates that longjmps are protected. Reviewers: ruiu, inglorion, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43217 llvm-svn: 325047
* [llvm-readobj] Fix double 0x prefix in RVA table printing after r321527Reid Kleckner2018-01-231-1/+1
| | | | llvm-svn: 323280
* [llvm-readobj] Consistent use of ScopedPrinterSam Clegg2018-01-101-3/+2
| | | | | | | | | There were a few places where outs() was being used directly rather than the ScopedPrinter object. Differential Revision: https://reviews.llvm.org/D41370 llvm-svn: 322141
* Fix tests after move to utohexstr.Benjamin Kramer2017-12-281-1/+1
| | | | llvm-svn: 321527
* Avoid int to string conversion in Twine or raw_ostream contexts.Benjamin Kramer2017-12-281-1/+1
| | | | | | Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
* [llvm-readobj] Support -needed-libs option for COFF filesPetr Hosek2017-12-271-0/+22
| | | | | | | | This implements the -needed-libs option in the COFF dumper. Differential Revision: https://reviews.llvm.org/D41529 llvm-svn: 321498
* Remove redundant includes from tools.Michael Zolotukhin2017-12-131-8/+0
| | | | llvm-svn: 320631
* Teach llvm-pdbutil to dump types from object files.Zachary Turner2017-12-051-0/+1
| | | | llvm-svn: 319859
* Split TypeTableBuilder into two classes.Zachary Turner2017-11-301-8/+9
| | | | llvm-svn: 319456
* Make TypeTableBuilder inherit from TypeCollection.Zachary Turner2017-11-291-2/+2
| | | | | | | | | | | | | | A couple of places in LLD were passing references to TypeTableCollections around, which makes it hard to change the implementation at runtime. However, these cases only needed to iterate over the types in the collection, and TypeCollection already provides a handy abstract interface for this purpose. By implementing this interface, we can get rid of the need to pass TypeTableBuilder references around, which should allow us to swap the implementation at runtime in subsequent patches. llvm-svn: 319345
* Convert a few ErrorOr to Expected.Rafael Espindola2017-10-111-4/+4
| | | | llvm-svn: 315477
* Follow up for r307085: a better fix for a dangling StringRef.Alexander Kornienko2017-07-261-6/+2
| | | | llvm-svn: 309092
* [codeview] Remove TypeServerHandler and PDBTypeServerHandlerReid Kleckner2017-07-171-2/+1
| | | | | | | | | | | | | | | | | Summary: Instead of wiring these through the CVTypeVisitor interface, clients should inspect the CVTypeArray before visiting it and potentially load up the type server's TPI stream if they need it. No tests relied on this functionality because LLD was the only client. Reviewers: ruiu Subscribers: mgorny, hiraditya, zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D35394 llvm-svn: 308212
* Fix dangling StringRefs found by clang-tidy misc-dangling-handle check.Alexander Kornienko2017-07-041-1/+5
| | | | llvm-svn: 307085
* [llvm-readobj] Improve printouts for COFF ARM64 binariesMartin Storsjo2017-06-301-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D34835 llvm-svn: 306795
* [llvm-readobj] Include the PE magic value in printoutsMartin Storsjo2017-06-301-0/+1
| | | | | | | | This is useful for a testcase in lld. Differential Revision: https://reviews.llvm.org/D34836 llvm-svn: 306794
* [llvm-readobj] Fix COFF RVA table dumping bugReid Kleckner2017-06-231-1/+5
| | | | | | | | We would return an error in getVaPtr if the RVA table being dumped was the last data in the .rdata section. Avoid the issue by subtracting one from the offset and adding it back to get an open interval again. llvm-svn: 306171
* [llvm-readobj] Dump the COFF image load configReid Kleckner2017-06-221-0/+133
| | | | | | | | This includes the safe SEH tables and the control flow guard function table. LLD will emit the guard table soon, and I need a tool that dumps them for testing. llvm-svn: 305979
* Delete TypeDatabase.Zachary Turner2017-06-181-1/+1
| | | | | | | | Merge the functionality into the random access type collection. This class was only being used in 2 places, so getting rid of it simplifies the code. llvm-svn: 305653
* Remove some dead code / includes.Zachary Turner2017-06-161-1/+0
| | | | | | | I'm trying to get rid of the TypeDatabase class, so the first step is to minimize its footprint. llvm-svn: 305611
* Update the test framework for llvm-cvtres to be more comprehensive.Eric Beckmann2017-06-131-5/+40
| | | | | | | | | | Summary: Added test cases for multiple machine types, file merging, multiple languages, and more resource types. Also fixed new bugs these tests exposed. Subscribers: javed.absar, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D34047 llvm-svn: 305258
* Revert "Fix alignment bug in COFF emission."Eric Beckmann2017-06-131-40/+5
| | | | | | | | | I accidentally combined this patch with one for adding more tests, they should be separated. This reverts commit 3da218a523be78df32e637d3446ecf97c9ea0465. llvm-svn: 305257
* Fix alignment bug in COFF emission.Eric Beckmann2017-06-131-5/+40
| | | | | | | | | | | | Summary: Fix alignment issue in D34020, by aligning all sections to 8 bytes. Reviewers: zturner Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D34072 llvm-svn: 305256
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | 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
* [CodeView] Properly align symbol records on read/write.Zachary Turner2017-06-011-1/+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] Add more DebugSubsection implementations.Zachary Turner2017-05-301-31/+30
| | | | | | | | 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-301-28/+28
| | | | | | | This is more concise, and matches the terminology used in other parts of the codebase more closely. llvm-svn: 304218
* Fix broken build.Zachary Turner2017-05-241-2/+1
| | | | llvm-svn: 303711
* Implement various flavors of type merging.Zachary Turner2017-05-221-2/+3
| | | | | | | | | | | | | | 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
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-35/+23
| | | | | | | | | | | | 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-23/+35
| | | | | | | | | | | | | | | | | | 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] Raise the source to ID map out of the TypeStreamMerger.Zachary Turner2017-05-181-2/+3
| | | | | | | This map will be needed to rewrite symbol streams after re-writing the corresponding type streams. llvm-svn: 303390
* [CodeView] Provide a common interface for type collections.Zachary Turner2017-05-181-36/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [BinaryStream] Reduce the amount of boiler plate needed to use.Zachary Turner2017-05-171-23/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Often you have an array and you just want to use it. With the current design, you have to first construct a `BinaryByteStream`, and then create a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer to the `BinaryByteStream`, so you can't just create a temporary one to appease the compiler, you have to actually hold onto both the `ArrayRef` as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of that. This makes for very cumbersome code, often requiring one to store a `BinaryByteStream` in a class just to circumvent this. At the cost of some added complexity (not exposed to users, but internal to the library), we can do better than this. This patch allows us to construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only does this reduce the amount of code you have to type and make it more obvious how to use it, but it solves real lifetime issues when it's inconvenient to hold onto a `BinaryByteStream` for a long time. The additional complexity is in the form of an added layer of indirection. Whereas before we simply stored a `BinaryStream*` in the ref, we now store both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When the user wants to construct a `BinaryStreamRef` directly from an `ArrayRef` etc, we allocate an internal object that holds ownership over a `BinaryByteStream` and forwards all calls, and store this in the `shared_ptr<>`. This also maintains the ref semantics, as you can copy it by value and references refer to the same underlying stream -- the one being held in the object stored in the `shared_ptr`. Differential Revision: https://reviews.llvm.org/D33293 llvm-svn: 303294
* Fix the Endianness bug by adding the little endian UTF marker.Eric Beckmann2017-05-091-0/+8
| | | | | | | | | | | | Summary: Quick fix Reviewers: zturner, uweigand Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33014 llvm-svn: 302573
* Hopefully one last commit to fix this patch, addresses string referenceEric Beckmann2017-05-081-3/+7
| | | | | | issues. llvm-svn: 302401
* Update llvm-readobj -coff-resources to display tree structure.Eric Beckmann2017-05-081-8/+93
| | | | | | | | | | | | Summary: Continue making updates to llvm-readobj to display resource sections. This is necessary for testing the up and coming cvtres tool. Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32609 llvm-svn: 302399
* Revert "Hopefully one last commit to fix this patch, addresses string reference"Eric Beckmann2017-05-081-97/+8
| | | | | | | | | | | | | | | | | | | | | Summary: This reverts commit 56beec1b1cfc6d263e5eddb7efff06117c0724d2. Revert "Quick fix to D32609, it seems .o files are not transferred in all cases." This reverts commit 7652eecd29cfdeeab7f76f687586607a99ff4e36. Revert "Update llvm-readobj -coff-resources to display tree structure." This reverts commit 422b62c4d302cfc92401418c2acd165056081ed7. Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32958 llvm-svn: 302397
* Hopefully one last commit to fix this patch, addresses string referenceEric Beckmann2017-05-081-2/+6
| | | | | | issues. llvm-svn: 302395
* Update llvm-readobj -coff-resources to display tree structure.Eric Beckmann2017-05-071-8/+93
| | | | | | | | | | | | Summary: Continue making updates to llvm-readobj to display resource sections. This is necessary for testing the up and coming cvtres tool. Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32609 llvm-svn: 302386
* [CodeView] Reserve TypeDatabase records up front.Zachary Turner2017-05-051-3/+3
| | | | | | | | | | | | | 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
* [llvm-readobj] Update readobj to re-use parsing code.Zachary Turner2017-05-031-41/+39
| | | | | | | | | | 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/CodeView] Read/write codeview inlinee line information.Zachary Turner2017-05-021-18/+12
| | | | | | | | 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
* [PDB/CodeView] Rename some classes.Zachary Turner2017-05-011-2/+2
| | | | | | | | | | | | 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
* [llvm-pdbdump] Abstract some of the YAML/Raw printing code.Zachary Turner2017-04-291-1/+1
| | | | | | | | | 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-readobj] Fix incorrect printing of CV column info.Zachary Turner2017-04-291-2/+4
| | | | llvm-svn: 301720
* [llvm-readobj] Use LLVMDebugInfoCodeView to parse line tables.Zachary Turner2017-04-281-48/+23
| | | | | | | | The llvm-readobj parsing code currently exists in our CodeView library, so we use that to parse instead of re-writing the logic in the tool. llvm-svn: 301718
* [llvm-readobj] Dump COFF Resources section.Zachary Turner2017-04-271-0/+25
| | | | | | | | | | | | This patch dumps the raw bytes of the .rsrc sections that are present in COFF object and executable files. Subsequent patches will parse this information and dump in a more human readable format. Differential Revision: https://reviews.llvm.org/D32463 Patch By: Eric Beckmann llvm-svn: 301578
* [CodeView] Isolate Debug Info Fragments into standalone classes.Zachary Turner2017-04-271-19/+13
| | | | | | | | | | | | | | | | | | | | | Previously parsing of these were all grouped together into a single master class that could parse any type of debug info fragment. With writing forthcoming, the complexity of each individual fragment is enough to warrant them having their own classes so that reading and writing of each fragment type can be grouped together, but isolated from the code for reading and writing other fragment types. In doing so, I found a place where parsing code was duplicated for the FileChecksums fragment, across llvm-readobj and the CodeView library, and one of the implementations had a bug. Now that the codepaths are merged, the bug is resolved. Differential Revision: https://reviews.llvm.org/D32547 llvm-svn: 301557
* Rename some PDB classes.Zachary Turner2017-04-271-22/+22
| | | | | | | | | | | | | | | | | | | We have a lot of very similarly named classes related to dealing with module debug info. This patch has NFC, it just renames some classes to be more descriptive (albeit slightly more to type). The mapping from old to new class names is as follows: Old | New ModInfo | DbiModuleDescriptor ModuleSubstream | ModuleDebugFragment ModStream | ModuleDebugStream With the corresponding Builder classes renamed accordingly. Differential Revision: https://reviews.llvm.org/D32506 llvm-svn: 301555
OpenPOWER on IntegriCloud