| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184468 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184268 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184263 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Currently, we only output the name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184255 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184191 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
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184022 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
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183955 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183954 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
These records are mandatory for executables and are used by the loader.
Reviewers: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D939
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183852 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
|
|
|
|
|
|
| |
Should bring bots back to life.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183715 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Apparently these macros have semicolons inside of them already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183712 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
|
|
|
|
|
|
| |
Thanks to David Blaikie for the suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183539 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183534 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
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183403 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
The previous name `Ref` is overly generic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183354 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
|
|
|
|
|
|
| |
And add a doxygen comment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183350 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
This avoids making assumptions about the data representation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183349 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Also, state an invariant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183348 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
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183293 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
It will be used for ELF dumping too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183287 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
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D905
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183087 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183043 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182954 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182914 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.
In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.
In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.
This patch exposes that in the ObjectFile API. It has the following advantages:
* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.
* llvm-readobj now prints relocations in the same way the native readelf does.
* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182908 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182898 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Should help the ppc32 buildbot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182194 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182169 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
In most cases the relocation type implies the object word size and
endianness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181509 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
It was only implemented for ELF where it collected the Addend, so this
patch also renames it to getRelocationAddend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181502 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All R_PPC_... relocs should also be present (using the same number)
under the corresponding R_PPC64_... name. The latter were missing
for a couple of cases, which this patch adds.
This is not a big problem when emitting the reloc, because we can
just use the R_PPC_... define instead. But it is a problem when
*dumping* relocations e.g. using llvm-readobj, because this will
expect only R_PPC64_... values when inspecting a ppc64 ELF file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181451 91177308-0d34-0410-b5e6-96231b3b80d8
|