Add an additional based relocation to the enumeration of based relocation names.
The lack of the enumerator value causes issues when inspecting WoA binaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226314 91177308-0d34-0410-b5e6-96231b3b80d8
This enhances llvm-readobj to print out the COFF export table, similar to the
-coff-import option. This is useful for testing in lld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225120 91177308-0d34-0410-b5e6-96231b3b80d8
It printed out base relocation table header as table entry.
This patch also makes llvm-readobj to not skip ABSOLUTE entries
becuase it was confusing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222299 91177308-0d34-0410-b5e6-96231b3b80d8
We claimed that we were printing the Subystem field when we were
actually printing the Characteristics field.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222216 91177308-0d34-0410-b5e6-96231b3b80d8
We were a little lax in a few areas:
- We pretended that import libraries were like any old COFF file, they
are not. In fact, they aren't really COFF files at all, we should
probably grow some specialized functionality to handle them smarter.
- Our symbol iterators were more than happy to attempt to go past the
end of the symbol table if you had a symbol with a bad list of
auxiliary symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222124 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Object is supposed to be robust to malformed object files. Don't
assert if we don't have a symbol table. I'll try to come up with a test
case later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221870 91177308-0d34-0410-b5e6-96231b3b80d8
Do a better job classifying symbols. This increases the consistency
between the COFF handling code and the ELF side of things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220952 91177308-0d34-0410-b5e6-96231b3b80d8
There are two methods in SectionRef that can fail:
* getName: The index into the string table can be invalid.
* getContents: The section might point to invalid contents.
Every other method will always succeed and returning and std::error_code just
complicates the code. For example, a section can have an invalid alignment,
but if we are able to get to the section structure at all and create a
SectionRef, we will always be able to read that invalid alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219314 91177308-0d34-0410-b5e6-96231b3b80d8
PE/COFF has a special section (.drectve) which can be used to pass options to
the linker (similar to LC_LINKER_OPTION). Add support to llvm-readobj to print
the contents of the section for tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219228 91177308-0d34-0410-b5e6-96231b3b80d8
Codeview line tables for functions in different sections refer to a common
STRING_TABLE_SUBSECTION for filenames.
This happens when building with -Gy or with inline functions with MSVC.
Original patch by Jeff Muizelaar!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219125 91177308-0d34-0410-b5e6-96231b3b80d8
This patch defines a new iterator for the imported symbols.
Make a change to COFFDumper to use that iterator to print
out imported symbols and its ordinals.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218915 91177308-0d34-0410-b5e6-96231b3b80d8
When the flag is given, the command prints out the COFF import table.
Currently only the import table directory will be printed.
I'm going to make another patch to print out the imported symbols.
The implementation of import directory entry iterator in
COFFObjectFile.cpp was buggy. This patch fixes that too.
http://reviews.llvm.org/D5569
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218891 91177308-0d34-0410-b5e6-96231b3b80d8
Users of getSectionContents shouldn't try to pass in BSS or virtual
sections. In all instances, this is a bug in the code calling this
routine.
N.B. Some COFF implementations (like CL) will mark their BSS sections as
taking space on disk. This would confuse COFFObjectFile into thinking
the section is larger than the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218549 91177308-0d34-0410-b5e6-96231b3b80d8
Teach WinCOFFObjectWriter how to write -mbig-obj style object files;
these object files allow for more sections inside an object file.
Our support for BigObj is notably different from binutils and cl: we
implicitly upgrade object files to BigObj instead of asking the user to
compile the same file *again* but with another flag. This matches up
with how LLVM treats ELF variants.
This was tested by forcing LLVM to always emit BigObj files and running
the entire test suite. A specific test has also been added.
I've lowered the maximum number of sections in a normal COFF file,
VS "14" CTP 3 supports no more than 65279 sections. This is important
otherwise we might not switch to BigObj quickly enough, leaving us with
a COFF file that we couldn't link.
yaml2obj support is all that remains to implement.
Differential Revision: http://reviews.llvm.org/D5349
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217812 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for reading the "bigobj" variant of COFF produced by
cl's /bigobj and mingw's -mbig-obj.
The most significant difference that bigobj brings is more than 2**16
sections to COFF.
bigobj brings a few interesting differences with it:
- It doesn't have a Characteristics field in the file header.
- It doesn't have a SizeOfOptionalHeader field in the file header (it's
only used in executable files).
- Auxiliary symbol records have the same width as a symbol table entry.
Since symbol table entries are bigger, so are auxiliary symbol
records.
Write support will come soon.
Differential Revision: http://reviews.llvm.org/D5259
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217496 91177308-0d34-0410-b5e6-96231b3b80d8
Add the new AppContainer characteristic which is import for Windows Store
(Metro) compatible applications. Add the new Control Flow Guard flag to bring
the enumeration up to date with the current values as of Windows 8.1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211855 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210803 91177308-0d34-0410-b5e6-96231b3b80d8
Add support to llvm-readobj to decode Windows ARM Exception Handling data. This
uses the previously added datastructures to decode the information into a format
that can be used by tests. This is a necessary step to add support for emitting
Windows on ARM exception handling information.
A fair amount of formatting inspiration is drawn from the Win64 EH printer as
well as the ARM EHABI printer. This allows for a reasonably thorough look into
the encoded data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210192 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the use of the std::function and replace the capturing lambda with a
non-capturing one, opting to pass the user data down to the context. This is
needed as std::function is not yet available on all hosted platforms (it
requires RTTI, which breaks on Windows).
Thanks to Nico Rieck for pointing this out!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209607 91177308-0d34-0410-b5e6-96231b3b80d8
Move the implementation of the Win64 EH printer from the COFFDumper into its own
class. This is in preparation for adding support to print ARM EH information.
The only real change here is in printUnwindInfo where we now lambda lift the
implicit this parameter for the resolveFunction. Also setup the printing to
handle ARM. This now has set the stage to introduce ARM EH printing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209606 91177308-0d34-0410-b5e6-96231b3b80d8
This inlines the single use function in preparation for splitting the Win64EH
printing out of the COFFDumper into its own entity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209605 91177308-0d34-0410-b5e6-96231b3b80d8
Make the use of the cache more transparent to the users. There is no reason
that the cached entries really need to be passed along. The overhead for doing
so is minimal: a single extra parameter. This requires that some standalone
functions be brought into the COFFDumper class so that they may access the
cache.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209604 91177308-0d34-0410-b5e6-96231b3b80d8
Switch to use references for parameters that are guaranteed to be non-null.
Simplifies the code a slight bit in preparation for another change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209603 91177308-0d34-0410-b5e6-96231b3b80d8
If a filename is a multiple of 18 characters, there will be no null-terminator.
This will result in an invalid access by the constructed StringRef. Add a test
case to exercise this and fix that handling. Address this same vulnerability in
llvm-readobj as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206145 91177308-0d34-0410-b5e6-96231b3b80d8
The current state of affairs has auxiliary symbols described as a big
bag of bytes. This is less than satisfying, it detracts from the YAML
file as being human readable.
Instead, allow for symbols to optionally contain their auxiliary data.
This allows us to have a much higher level way of describing things like
weak symbols, function definitions and section definitions.
This depends on D3105.
Differential Revision: http://llvm-reviews.chandlerc.com/D3092
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204214 91177308-0d34-0410-b5e6-96231b3b80d8
