Previously message told us that relocations could
not be used when making shared object. That was
correct because message could appear (and it is expected)
when we linked executable.
Message should have being changed to something
that says we can't use a subset of relocations against shared
symbols.
Patch fixes the text.
llvm-svn: 272478
Add support for an ARM Target and the initial set of relocations
and PLT entries that are necessary for an ARM only hello world to
link. This has been tested against an ARM only sysroot from the
4.2.0 CodeSourcery Lite release.
Tests have been added to test/ELF for the support that has been
implemented.
Main limitations:
- No Thumb support
- Relocations incomplete
- No C++ exceptions support
- No TLS support
- No range extension or interworking veneer (thunk) support
- No Build Attribute support
- No Big-endian support
The deprecated relocations R_ARM_PLT32 and R_ARM_PC24 have been
implemented as these are used by the 4.2.0 CodeSourcery Lite release.
llvm-svn: 271993
This is mostly extracted from http://reviews.llvm.org/D18960.
The general idea for tlsdesc is that the two GD got entries are used
for a function pointer and its argument. The dynamic linker sets
both. In the non-dlopen case the dynamic linker sets the function to
the identity and the argument to the offset in the tls block.
All that the static linker has to do in the non-dlopen case is
relocate the code to point to the got entries and create a dynamic
relocation.
The dlopen case is more complicated, but can be implemented in another patch.
llvm-svn: 271569
Patch implements next relaxation from latest ABI:
"Convert memory operand of test and binop into immediate operand, where binop is one of adc, add, and, cmp, or,
sbb, sub, xor instructions, when position-independent code is disabled."
It is described in System V Application Binary Interface AMD64 Architecture Processor
Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf,
B.2 "B.2 Optimize GOTPCRELX Relocations").
Differential revision: http://reviews.llvm.org/D20793
llvm-svn: 271405
D15779 introduced basic approach to support new relaxations.
This patch implements relaxations for jmp and call instructions,
described in System V Application Binary Interface AMD64 Architecture Processor
Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf,
B.2 "B.2 Optimize GOTPCRELX Relocations")
Differential revision: http://reviews.llvm.org/D20622
llvm-svn: 270721
System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8
(https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations")
introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX.
That patch implements the next relaxation:
mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg
and also opens door for implementing all other ones.
Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself.
Differential revision: http://reviews.llvm.org/D15779
llvm-svn: 270705
This makes it explicit that each R_RELAX_TLS_* is equivalent to some
other expression.
With this I think we are at a sweet spot for how much is done in
Target.cpp. I did experiment with moving *all* the value math out of it.
It has the advantage that we know the final value in target independent
code, but it gets quite verbose.
llvm-svn: 270277
This adds direct support for computing offsets from the thread pointer
for both variants. Of the architectures we support, variant 1 is used
only by aarch64 (but that doesn't seem to be documented anywhere.)
llvm-svn: 270243
Lazy binding is quite important for use case like a shared build of
llvm. Also, if someone wants to disable it, it is better done in the
compiler (disable plt generation).
The only reason to keep it is to make it easier to add a new
architecture. But it doesn't really help much as it is possible to start
with non lazy relocation and plt code but still let the generic part
create a dedicated .got.plt and .rela.plt.
llvm-svn: 269982
New names reflect purpose of corresponding GOT entries better.
Both expression types related to entries allocated in the 'local'
part of MIPS GOT. R_MIPS_GOT_LOCAL_PAGE is for entries contain 'page'
addresses. R_MIPS_GOT_LOCAL is for entries contain 'full' address.
llvm-svn: 269597
MIPS N64 ABI packs multiple relocations into the single relocation
record. In general, all up to three relocations can have arbitrary types.
In fact, Clang and GCC uses only a few combinations. For now, we support
two of them. That is allow to pass at least all LLVM test suite cases.
<any relocation> / R_MIPS_SUB / R_MIPS_HI16 | R_MIPS_LO16
<any relocation> / R_MIPS_64 / R_MIPS_NONE
The first relocation is a 'real' relocation which is calculated using
the corresponding symbol's value. The second and the third relocations
used to modify result of the first one: extend it to 64-bit, extract
high or low part etc. For details, see part 2.9 'Relocation' at
https://dmz-portal.mips.com/mw/images/8/82/007-4658-001.pdf
llvm-svn: 268876
MIPS N64 ABI packs multiple relocations into the single relocation
record. Particularly it requires to represent dynamic relative
relocation as a combination of R_MIPS_REL32 and R_MIPS_64 relocations.
llvm-svn: 268565
We were already checking for non relative relocations.
If we ever decide to add support for rw text segments this means we will
have a single spot to add the flag.
llvm-svn: 268558
These relocations introduced by MIPS N64 ABI. R_MIPS_GOT_DISP references
GOT entry with full symbol's address, R_MIPS_GOT_PAGE creates GOT entry
with address of memory page which includes symbol's address,
R_MIPS_GOT_OFST used together with R_MIPS_GOT_PAGE. This relocation
calculates offset from beginning of memory page to the symbol address.
llvm-svn: 268525
