The patch implements support for both relocation record formats: Elf_Rel
and Elf_Rela. It is possible to define relocation against symbol only.
Relocations against sections will be implemented later. Now yaml2obj
recognizes X86_64, MIPS and Hexagon relocation types.
Example of relocation section specification:
Sections:
- Name: .text
Type: SHT_PROGBITS
Content: "0000000000000000"
AddressAlign: 16
Flags: [SHF_ALLOC]
- Name: .rel.text
Type: SHT_REL
Info: .text
AddressAlign: 4
Relocations:
- Offset: 0x1
Symbol: glob1
Type: R_MIPS_32
- Offset: 0x2
Symbol: glob2
Type: R_MIPS_CALL16
The patch reviewed by Michael Spencer, Sean Silva, Shankar Easwaran.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206017 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce ScalarTraits::mustQuote which determines whether or not a
StringRef needs quoting before it is acceptable to output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205955 91177308-0d34-0410-b5e6-96231b3b80d8
Don't quote octal compatible strings if they are only two wide, they
aren't ambiguous.
This reverts commit r205857 which reverted r205857.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205914 91177308-0d34-0410-b5e6-96231b3b80d8
obj2yaml would fail when seeing a Weak External auxiliary record with a
characteristics field holding zero instead of one of
IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY, IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY,
or IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205911 91177308-0d34-0410-b5e6-96231b3b80d8
YAMLIO would turn a BinaryRef into the string 0000000004000000.
However, the leading zero causes parsers to interpret it as being an
octal number instead of a hexadecimal one.
Instead, escape such strings as needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205839 91177308-0d34-0410-b5e6-96231b3b80d8
The IO normalizer would essentially lump I386 and AMD64 relocations
together. Relocation types with the same numeric value would then get
mapped in appropriately.
For example:
IMAGE_REL_AMD64_ADDR64 and IMAGE_REL_I386_DIR16 both have a numeric
value of one. We would see IMAGE_REL_I386_DIR16 in obj2yaml conversions
of object files with a machine type of IMAGE_FILE_MACHINE_AMD64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205746 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r205479.
It turns out that nm does use addresses, it is just that every reasonable
relocatable ELF object has sections with address 0. I have no idea if those
exist in reality, but it at least it shows that llvm-nm should use the name
address.
The added test was includes an unusual .o file with non 0 section addresses. I
created it by hacking ELFObjectWriter.cpp.
Really sorry for the churn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205493 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The FileHeader mapping now accepts an optional Flags sequence that accepts
the EF_<arch>_<flag> constants. When not given, Flags defaults to zero.
Reviewers: atanasyan
Reviewed By: atanasyan
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3213
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205173 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
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.
Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201881 91177308-0d34-0410-b5e6-96231b3b80d8
COFF has only one symbol table.
MachO has a LC_DYSYMTAB, but that is not a symbol table, just extra info about
the one symbol table (LC_SYMTAB).
IR (coming soon) also has only one table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200488 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a regression introduced by r182908, which broke
llvm-objdump's ability to display relocations inline in a disassembly
dump for ELF object files.
That change removed a SectionRelocMap from Object/ELF.h, which we
recreate in llvm-objdump.cpp.
I discovered this regression via an out-of-tree test
(test/NaCl/X86/pnacl-hides-sandbox-x86-64.ll) which used llvm-objdump.
Note that the "Unknown" string in the test output on i386 isn't quite
right, but this appears to be a pre-existing bug.
Differential Revision: http://llvm-reviews.chandlerc.com/D2559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200090 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196471 91177308-0d34-0410-b5e6-96231b3b80d8
Linux cannot open directories with open(2), although cygwin and *bsd can.
Motivation: The test, Object/directory.ll, had been failing with --target=cygwin on Linux. XFAIL was improper for host issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194257 91177308-0d34-0410-b5e6-96231b3b80d8
There is still a long way to go for llvm-nm, but at least we now match
nm's letter output in the cases we test for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193912 91177308-0d34-0410-b5e6-96231b3b80d8
This is just enough to get "llvm-ranlib foo.a" working and tested. Making
llvm-ranlib a symbolic link to llvm-ar doesn't work so well with llvm's option
parsing, but ar's option parsing is mostly custom anyway.
This patch also removes the -X32_64 option. Looks like it was just added in
r10297 as part of implementing the current command line parsing. I can add it
back (with a test) if someone really has AIX portability problems without it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189489 91177308-0d34-0410-b5e6-96231b3b80d8
- Instead of setting the suffixes in a bunch of places, just set one master
list in the top-level config. We now only modify the suffix list in a few
suites that have one particular unique suffix (.ml, .mc, .yaml, .td, .py).
- Aside from removing the need for a bunch of lit.local.cfg files, this enables
4 tests that were inadvertently being skipped (one in
Transforms/BranchFolding, a .s file each in DebugInfo/AArch64 and
CodeGen/PowerPC, and one in CodeGen/SI which is now failing and has been
XFAILED).
- This commit also fixes a bunch of config files to use config.root instead of
older copy-pasted code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188513 91177308-0d34-0410-b5e6-96231b3b80d8
* ELFTypes.h contains template magic for defining types based on endianess, size, and alignment.
* ELFFile.h defines the ELFFile class which provides low level ELF specific access.
* ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188022 91177308-0d34-0410-b5e6-96231b3b80d8
If no other operation is specified, 's' becomes an operation instead of an
modifier. The s operation just creates a symbol table. It is the same as
running ranlib.
We assume the archive was created by a sane ar (like llvm-ar or gnu ar) and
if the symbol table is present, then it is current. We use that to optimize
the most common case: a broken build system that thinks it has to run ranlib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187353 91177308-0d34-0410-b5e6-96231b3b80d8
The symbol table has forward references in the file. Instead of allocating
a temporary buffer or counting the size and then writing, this implementation
writes a dummy value first and patches it once the final value is known.
There is room for performance improvement. I will implement them as soon as I
get some other features (like a ranlib mode) in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186934 91177308-0d34-0410-b5e6-96231b3b80d8
This matches gnu archive behavior and since archive member order can change
which member is used, not changing the order on replacement looks like the
right thing to do.
This patch also refactors the logic for which archive member to keep and
whether to move it to a helper function (computeInsertAction). The
nesting in computeNewArchiveMembers was getting a bit confusing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186829 91177308-0d34-0410-b5e6-96231b3b80d8
GNU ar when not given the a or b modifiers replaces archive members in the
same location of the old ones. I am about to implement that in llvm-ar. For
now, just don't depend on the current llvm-ar behavior on this test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186823 91177308-0d34-0410-b5e6-96231b3b80d8
We were incorrectly computing where to insert a member if it was replacing
a previous member that was before the insert point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186792 91177308-0d34-0410-b5e6-96231b3b80d8
This has some advantages:
* Lets us use native, utf16 windows functions.
* Easy to produce good errors on windows about trying to use a
directory when we want a file.
* Simplifies the unix version a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186511 91177308-0d34-0410-b5e6-96231b3b80d8
