Add VK_... values and relocation types necessary to support
the @got family of modifiers. Used by the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184860 91177308-0d34-0410-b5e6-96231b3b80d8
Although in reality the symbol table in ELF resides in a section, the
standard requires that there be no more than one SHT_SYMTAB. To enforce
this constraint, it is cleaner to group all the symbols under a
top-level `Symbols` key on the object file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184627 91177308-0d34-0410-b5e6-96231b3b80d8
The GNU assembler supports (as extension to the ABI) use of PC-relative
relocations in half16 fields, which allows writing code like:
li 1, base-.
This patch adds support for those relocation types in the assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184552 91177308-0d34-0410-b5e6-96231b3b80d8
The current code base only supports the minimum set of tls-related
relocations and @modifiers that are necessary to support compiler-
generated code. This patch extends this to the full set defined
in the ABI (and supported by the GNU assembler) for the benefit
of the assembler parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184551 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the @higher, @highera, @highest, and @highesta
modifers, including some missing relocation types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184550 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the relocation type and other necessary infrastructure
to use the @toc@h modifier in the assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184549 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, just have 3 sub-lists, one for each of
{STB_LOCAL,STB_GLOBAL,STB_WEAK}.
This allows us to be a lot more explicit w.r.t. the symbol ordering in
the object file, because if we allowed explicitly setting the STB_*
`Binding` key for the symbol, then we might have ended up having to
shuffle STB_LOCAL symbols to the front of the list, which is likely to
cause confusion and potential for error.
Also, this new approach is simpler ;)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184506 91177308-0d34-0410-b5e6-96231b3b80d8
After this patch, the ELF file produced by
`yaml2obj-elf-symbol-basic.yaml`, when linked and executed on x86_64
(under SysV ABI, obviously; I tested on Linux), produces a working
executable that goes into an infinite loop!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184469 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the compiler to see the enum and warn about it. While in here,
fix a switch to not use a default and fix style violations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184186 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-objdump should provide some way of printing out the addends present in the
.rela sections for debugging purposes if nothing else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184072 91177308-0d34-0410-b5e6-96231b3b80d8
For consistency, change the address in the test case from 0xDEADBEEF to
0xCAFEBABE since 0xCAFEBABE that actually has a 2-byte alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183962 91177308-0d34-0410-b5e6-96231b3b80d8
The current functionality is extremely basic and a bit rough around the
edges, but it will flesh out in future commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183953 91177308-0d34-0410-b5e6-96231b3b80d8
COFF header is always present both in executable and in object file. PE header
is present only in executable. So the natural way to handle PE/COFF file is
treating COFF is mandatory header and PE is optional. Current data structre
does not allow it, because PE header includes COFF header. Removing COFF
header will simplify the code to handle PE/COFF files.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D952
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183788 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, only emitting the ELF header is supported (no sections or
segments).
The ELFYAML code organization is broadly similar to the COFFYAML code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183711 91177308-0d34-0410-b5e6-96231b3b80d8
from the LC_DATA_IN_CODE load command. And when disassembling print
the data in code formatted for the kind of data it and not disassemble those
bytes.
I added the format specific functionality to the derived class MachOObjectFile
since these tables only appears in Mach-O object files. This is my first
attempt to modify the libObject stuff so if folks have better suggestions
how to fit this in or suggestions on the implementation please let me know.
rdar://11791371
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
A user shouldn't care about the internal state, and these methods by
their very nature require asserting a predicate on the internal state.
As such, they cannot be used safely without introducing hidden
long-distance dependencies on the manner of construction of the
BinaryRef.
Use writeAsBinary(raw_ostream &) and writeAsHex(raw_ostream &) if you
need to access the data in a binary or hex format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183353 91177308-0d34-0410-b5e6-96231b3b80d8
This hides the implementation. A future commit will remove the
error-prone getHex() and getBinary() methods.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183352 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, yaml2coff.cpp had a writeHexData static helper function to
do this, but it is generally useful functionality.
Also, validate hex strings up-front to avoid running having to handle
errors "deep inside" the yaml2obj code (it also gives better diagnostics
than it used to).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183345 91177308-0d34-0410-b5e6-96231b3b80d8
The first symbol on ELF is dummy, but it has a defined content and readelf
normally displays it. With this change llvm-readobj also displays it and we
can check that llvm-mc output is correct according to the standard.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183337 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch we use the SectionIndex directly, instead of counting the
number of symbol tables. This saves a DenseMap lookup every time we want to
find which symbol a relocation refers to.
Also simplify based on the fact that there is at most one SHT_SYMTAB and one
SHT_DYNSYM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183326 91177308-0d34-0410-b5e6-96231b3b80d8
In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183284 91177308-0d34-0410-b5e6-96231b3b80d8
