MIPS64 ELF file has a very specific relocation record format. Each
record might specify up to three relocation operations. So the `r_info`
field in fact consists of three relocation type sub-fields and optional
code of "special" symbols.
http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf
page 40
The patch implements support of the MIPS64 relocation record format in
yaml2obj/obj2yaml tools by introducing new optional Relocation fields:
Type2, Type3, and SpecSym. These fields are recognized only if the
object/YAML file relates to the MIPS64 target.
Differential Revision: http://reviews.llvm.org/D7136
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227044 91177308-0d34-0410-b5e6-96231b3b80d8
be exported from a dylib if their containing object file were linked into one.
No test case: No command line tools query this flag, and there are no Object
unit tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226217 91177308-0d34-0410-b5e6-96231b3b80d8
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225974 91177308-0d34-0410-b5e6-96231b3b80d8
Also corrected the name of the load command to not end in an ’S’ as well as corrected
the name of the MachO::linker_option_command struct and other places that had the
word option as plural which did not match the Mac OS X headers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224485 91177308-0d34-0410-b5e6-96231b3b80d8
Add in definedness checks for shift operators, null checks when
pointers are assumed by the code to be non-null, and explicit
unreachables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224255 91177308-0d34-0410-b5e6-96231b3b80d8
These methods are only used by MCJIT and are very specific to it. In fact, they
are also fairly specific to the fact that we have a dynamic linker of
relocatable objects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223964 91177308-0d34-0410-b5e6-96231b3b80d8
It is a static method of IRObjectFile, so having to use
IRObjectFile::createIRObjectFile was redundant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223822 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, walk the obj symbol list in parallel to find the GV. This shouldn't
change anything on ELF where global symbols are not mangled, but it is a step
toward supporting other object formats.
Gold itself is ELF only, but bfd ld supports COFF and the logic in the gold
plugin could be reused on lld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223780 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-objdump printed out an error message for this off-by-one error,
but because it always exits with 0 whether or not it found an error,
the test (llvm-objdump/coff-many-relocs.test) succeeded.
I made llvm-objdump exit with EXIT_FAILURE when an error is found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222852 91177308-0d34-0410-b5e6-96231b3b80d8
We can now use the ELF relocation .def files to create the mapping
of relocation numbers to names and avoid having to duplicate the
list of relocations.
Patch by Will Newton.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222567 91177308-0d34-0410-b5e6-96231b3b80d8
We can now use the ELF relocation .def files to create the mapping
of relocation numbers to names and avoid having to duplicate the
list of relocations.
Patch by Will Newton.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222566 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 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
In support of serializing executables, obj2yaml now records the virtual address
and size of sections. It also serializes whatever we strictly need from
the PE header, it expects that it can reconstitute everything else via
inference.
yaml2obj can reconstitute a fully linked executable.
In order to get executables correctly serialized/deserialized, other
bugs were fixed as a circumstance. We now properly respect file and
section alignments. We also avoid writing out string tables unless they
are strictly necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221975 91177308-0d34-0410-b5e6-96231b3b80d8
Split getObject's smarts into checkOffset, use this to replace the
handwritten check in getSectionContents. Similarly, replace checks in
section_rel_begin/section_rel_end with getNumberOfRelocations.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221873 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
getObject didn't consider the case where a pointer came before the start
of the object file. No test is included, trying to come up with
something reasonable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221868 91177308-0d34-0410-b5e6-96231b3b80d8