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
Now that we have a lib/MC/MCAnalysis, the dependency was there just because
of two helper classes. Move the two over to MC.
This will allow IRObjectFile to parse inline assembly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212248 91177308-0d34-0410-b5e6-96231b3b80d8
interface methods isCOFF().
The '-coff' command line option has been removed. It was not used in any
test cases.
The patch reviewed by Michael Spencer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208157 91177308-0d34-0410-b5e6-96231b3b80d8
obj2yaml would emit the NUL bytes padding the auxiliary file symbol
records. Trimming them looks nicer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204314 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
None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().
This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of a future patch to use yamlio that incorrectly ended up in a
cleanup patch.
Thanks to Benjamin Kramer for reporting it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179938 91177308-0d34-0410-b5e6-96231b3b80d8
