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
It is now used only for relocations that only set the low bits inside a
page. Everything else is handled by getRelExpr.
I will send a another review renaming and better documenting
isRelRelative.
llvm-svn: 267705
MIPS is the only target requires GOT header. We already have MIPS
specific code in the `GotSection` class, so move MIPS GOT header
generation there and delete redundant stuff like `GotHeaderEntriesNum`
field and `writeGotHeader` method.
Differential Revision: http://reviews.llvm.org/D19465
llvm-svn: 267460
These relocations are calculated as S + A - DTPREL or S + A - TPREL,
where DTPREL = TlsVA - 0x8000, TPREL = TlsVA - 0x7000. So the result
is relative to the TLS output section and is not an absolut value
The fix allows to escape creation of unnecessary dynamic relocations
in case of DSO linking.
llvm-svn: 266923
It is now redundant. Writer.cpp can reason that 2 dynamic relocations
are needed: one to find the final got entry address and one to fill the
got entry.
llvm-svn: 266876
This requires adding a few more expression types, but is already a small
simplification. Having Writer.cpp know the exact expression will also
allow further simplifications.
llvm-svn: 266604
The _gp_disp symbol designates offset between start of function and 'gp'
pointer into GOT. The following code is a typical MIPS function preamble
used to setup $gp register:
lui $gp, %hi(_gp_disp)
addi $gp, $gp, %lo(_gp_disp)
To calculate R_MIPS_HI16 / R_MIPS_LO16 relocations results we use
the following formulas:
%hi(_gp - P + A)
%lo(_gp - P + A + 4),
where _gp is a value of _gp symbol, A is addend, and P current address.
The R_MIPS_LO16 relocation references _gp_disp symbol is always the second
instruction. That is why we need four byte adjustments. The patch assigns
R_PC type for R_MIPS_LO16 relocation and adjusts its addend by 4. That fix
R_MIPS_LO16 calculation.
For details see p. 4-19 at ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
Differential Revision: http://reviews.llvm.org/D19115
llvm-svn: 266368
With this patch we use the first scan over the relocations to remember
the information we found about them: will them be relaxed, will a plt be
used, etc.
With that the actual relocation application becomes much simpler. That
is particularly true for the interfaces in Target.h.
This unfortunately means that we now do two passes over relocations for
non SHF_ALLOC sections. I think this can be solved by factoring out the
code that scans a single relocation. It can then be used both as a scan
that record info and for a dedicated direct relocation of non SHF_ALLOC
sections.
I also think it is possible to reduce the number of enum values by
representing a target with just an OutputSection and an offset (which
can be from the start or end).
This should unblock adding features like relocation optimizations.
llvm-svn: 266158
This patch fixes dynamic relocation creation from GOT access in dynamic
objects on aarch64. Current code creates a plt relative one
(R_AARCH64_JUMP_SLOT) instead of a got relative (R_AARCH64_GLOB_DAT).
It leads the programs fails with:
$ cat t.cc
std::string test = "hello...\n";
int main ()
{
printf ("%s\n", test.c_str());
return 0;
}
$ clang++ t.cc -fpic -o t
$ ./t
hello...
Segmentation fault (core dumped)
Due the fact it will try to access the plt instead of the got for
__cxa_atexit registration for the std::string destruction. It will
lead in a bogus function address in atexit.
llvm-svn: 265784
Similar to r265462, TLS related relocations aren't marked as relative,
meaning that we end up generating R_AARCH64_RELATIVE relocations for
them. This change adds TLS relocations that I've seen on my system. With
this patch applied CloudABI's unit testing binary now passes on aarch64.
Approved by: ruiu
Differential Revision: http://reviews.llvm.org/D18816
llvm-svn: 265575
While trying to get PIE work on CloudABI for x86-64, I noticed that even
though GNU ld would generate functional binaries, LLD would not. It
turns out that we generate relocations for referencing TLS objects
inside of the text segment, which shouldn't happen.
This change extends the isRelRelative() function to list some additional
relocation types that should be treated as relative. This makes my C
library unit testing binary work on x86-64.
Approved by: ruiu
Differential Revision: http://reviews.llvm.org/D18688
Fixes bug: https://llvm.org/bugs/show_bug.cgi?id=27174
llvm-svn: 265462
Our symbol representation was redundant, and some times would get out of
sync. It had an Elf_Sym, but some fields were copied to SymbolBody.
Different parts of the code were checking the bits in SymbolBody and
others were checking Elf_Sym.
There are two general approaches to fix this:
* Copy the required information and don't store and Elf_Sym.
* Don't copy the information and always use the Elf_Smy.
The second way sounds tempting, but has a big problem: we would have to
template SymbolBody. I started doing it, but it requires templeting
*everything* and creates a bit chicken and egg problem at the driver
where we have to find ELFT before we can create an ArchiveFile for
example.
As much as possible I compared the test differences with what gold and
bfd produce to make sure they are still valid. In most cases we are just
adding hidden visibility to a local symbol, which is harmless.
In most tests this is a small speedup. The only slowdown was scylla
(1.006X). The largest speedup was clang with no --build-id, -O3 or
--gc-sections (i.e.: focus on the relocations): 1.019X.
llvm-svn: 265293
The extra fix is to note that it still requires copy relocations.
Original message:
Change how we handle R_MIPS_LO16.
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
P.S.: Suggestions for a better name for the predicate are welcome :-)
llvm-svn: 265150
Some targets might require creation of thunks. For example, MIPS targets
require stubs to call PIC code from non-PIC one. The patch implements
infrastructure for thunk code creation and provides support for MIPS
LA25 stubs. Any MIPS PIC code function is invoked with its address
in register $t9. So if we have a branch instruction from non-PIC code
to the PIC one we cannot make the jump directly and need to create a small
stub to save the target function address.
See page 3-38 ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
- In relocation scanning phase we ask target about thunk creation necessity
by calling `TagetInfo::needsThunk` method. The `InputSection` class
maintains list of Symbols requires thunk creation.
- Reassigning offsets performed for each input sections after relocation
scanning complete because position of each section might change due
thunk creation.
- The patch introduces new dedicated value for DefinedSynthetic symbols
DefinedSynthetic::SectionEnd. Synthetic symbol with that value always
points to the end of the corresponding output section. That allows to
escape updating synthetic symbols if output sections sizes changes after
relocation scanning due thunk creation.
- In the `InputSection::writeTo` method we write thunks after corresponding
input section. Each thunk is written by calling `TargetInfo::writeThunk` method.
- The patch supports the only type of thunk code for each target. For now,
it is enough.
Differential Revision: http://reviews.llvm.org/D17934
llvm-svn: 265059
We have to check the final value that is written.
I don't think this has any real word implications (unless something
supports unaligned instructions), but unblocks simplifying the handling
of PC relative relocations.
llvm-svn: 265009
If we make R_MIPS_LO16 a relative relocation, linker:
- never creates R_MIPS_COPY relocation for it
- attempts to create R_MIPS_REL32 dynamic relocation if R_MIPS_LO16's
target is a preemptible symbol
Differential Revision: http://reviews.llvm.org/D18607
llvm-svn: 264956
This simplifies a few things
* Read the value as early as possible, instead of passing a pointer to
the location.
* Print the warning for missing pair close to where we find out it is
missing.
* Don't pass the value to relocateOne.
llvm-svn: 264802
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
llvm-svn: 264761
When R_X86_64_PC32/R_X86_64_32 relocations are
used against preemptible symbol and output is position independent,
error should be generated.
Differential revision: http://reviews.llvm.org/D18190
llvm-svn: 264707
This patch simplifies the isRelRelative for AArch64 and add the missing
ones for bootstrap and test-suite. It also adds more testing for
shared object creation.
llvm-svn: 264322
R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX relocations were added in latest ABI:
https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf
They should be generated instead of R_X86_64_GOTPCREL for cases
when relaxation is possible. Currently this patch just process them in the
same way like R_X86_64_GOTPCREL. That should work for now
and we can implement relaxations later.
There is no testcases provided as I think there is no way to generate
such relocations using llvm-mc atm.
Differential revision: http://reviews.llvm.org/D18301
llvm-svn: 264043
-pie
--pic-executable
Create a position independent executable. This is currently only
supported on ELF platforms. Position independent executables are
similar to shared libraries in that they are relocated by the
dynamic linker to the virtual address the OS chooses for them
(which can vary between invocations). Like normal dynamically
linked executables they can be executed and symbols defined in the
executable cannot be overridden by shared libraries.
Differential revision: http://reviews.llvm.org/D18183
llvm-svn: 263693
We want to make SymbolBody the central place to query symbol information.
This patch also renames canBePreempted to isPreemptible because I feel that
the latter is slightly better (the former is three words and the latter
is two words.)
llvm-svn: 263386
which was reverted because included
unrelative changes by mistake.
Original commit message:
[ELF] - Change all messages to lowercase to be consistent.
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263337
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263252
It was discussed to make all messages be
lowercase to be consistent with clang.
(also reverts the r263128 which fixed
build bot fail after r263125)
Original commit message:
[ELF] - Consistent spelling for error/warning messages
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263240
R_X86_64_DTPOFF64 was not handled properly.
Next sample app was impossible to link before this patch:
~/pg/release/bin/clang -target x86_64-pc-linux testthread.cpp -c -g
~/pg/d+a/bin/ld.lld testthread.o
"Unknown TLS optimization" (value was 17)
__thread int x = 0;
void _start() {
}
It works fine now.
Differential revision: http://reviews.llvm.org/D18039
llvm-svn: 263150
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263125
It was a badly specified hack for when a tls relocation should be
propagated to the dynamic relocation table.
This replaces it with a not as bad hack of saying that a local dynamic
tls relocation is never preempted.
I will try to remove even that second hack in the next patch.
llvm-svn: 262955
Get rid of few accessors in that class, and replace
them with direct fields access.
Differential revision: http://reviews.llvm.org/D17879
llvm-svn: 262796
Patch changes the return type of Target::relaxTls
to size_t from unsigned. That is consistent with
its use from other code.
Change was reviewed http://reviews.llvm.org/D17882
and asked to commit separately from that patch above.
llvm-svn: 262794
Patch changes all relocations types to be uint32_t and also
fixes some dependent inconsistency in callers code.
Differential revision: http://reviews.llvm.org/D17882
llvm-svn: 262793
The rules for when we can relax tls relocations are target independent.
The only things that are target dependent are the relocation values.
llvm-svn: 262748
SymbolBody constructor and friends take isFunc and isTLS boolean arguments.
ELF symbols have already a type so than be easily passed as argument.
If we want to support another type, this scheme is not good enough, that is,
the current code logic would require passing another `bool isObject` around.
Up to two argument, this stretching exercise was a little bit goofy but
still acceptable, but with more types to support, is just too much, IMHO.
Change the code so that the type is passed instead.
Differential Revision: http://reviews.llvm.org/D17871
llvm-svn: 262684
The hack of using a plt address as the address of an undefined function
only works in executables. Don't try it with shared libraries.
llvm-svn: 262642
For shared libraries we allow any weak undefined symbol to eventually be
resolved, even if we never see a definition in another .so. This matches
the behavior when handling other undefined symbols in a shared library.
For executables, we require seeing a definition in a .so or resolve it
to zero. This is also similar to how non weak symbols are handled.
llvm-svn: 262017
When this code was first added it was compensating for the code deciding
to create plt entries for directly referenced functions being too aggressive.
That has since been fixed, so we don't need this anymore.
llvm-svn: 261933
This commit does two related thing. At first, it enumerates supported
absolute MIPS relocations in the `MipsTargetInfo<ELFT>::isRelRelative`
method. In that case the code is shorter and the case switch does not
tend to grow. At second, it prevents R_MIPS_COPY and PLT creation for
relative relocations. For almost all relative MIPS relocations like
R_MIPS_PC19_S2, R_MIPS_PCHI16 etc it does not have a sence. The only
exception is R_MIPS_PC32. GNU linker creates a copy relocation or PLT
entry for it. But I could not find any real test case uses R_MIPS_PC32
with DSO defined symbol as a target. So for now I prefer to skip this
case to simplify the LLD code.
llvm-svn: 261822
There is nothing aarch64 specific in here. If a symbol can be preempted,
we need to copy the full relocation to the dynamic linker.
If a symbol cannot be preempted, we can make the dynamic linker life
easier and produce a relative relocation.
This is directly equivalent to R_X86_64_64 to R_x86_64_RELATIVE
conversion.
llvm-svn: 261678
This patch fixes the R_AARCH64_ABS64 relocation when used in shared mode,
where it requires a dynamic R_AARCH64_RELATIVE relocation. To correct set
the addend on the dynamic relocation (since it will be used by the dynamic
linker), a new TargetInfo specific hook was created (getDynRelativeAddend)
to get the correct addend based on relocation type.
The patch fixes the issues when creating shared library code against
{init,fini}_array, where it issues R_AARCH64_ABS64 relocation against
local symbols.
llvm-svn: 261651
This patch adds some TLS relocations and relaxations for AArch64.
Some Global-Dynamic relocation are handled by optimizing them to
Local-Exec (Initial-Exec is not yet supported). They are:
- R_AARCH64_TLSDESC_ADR_PAGE21
- R_AARCH64_TLSDESC_LD64_LO12_NC
- R_AARCH64_TLSDESC_ADD_LO12_NC
- R_AARCH64_TLSDESC_CALL
Also some Init-Exec is optimized to Local-Exec if possible. They are:
- R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21
- R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
Finally some Local-Exec relocation are handled in relocateOne:
- R_AARCH64_TLSLE_ADD_TPREL_HI12
- R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
This work is mainly for compiler bootstrap, where static binaries is
showing good progress (although shared object still lacking support
from both TLS aarch64 backend and some other issues).
llvm-svn: 260677
Previously, Target held a value until a new value is assigned to the
variable. That was a benign leak -- that was not an unbounded leak
and didn't grab any resources except a small amount of memory. But
it is better to fix than leaving as is.
llvm-svn: 260592
R_X86_64_TPOFF64 is a dynamic relocation,
it should not appear in static relocation processing.
Patch fixes it.
Differential revision: http://reviews.llvm.org/D16880
llvm-svn: 260508
The patch adds lazy relocation support for MIPS and R_MIPS_26 relocation
handing.
R_MIPS_26 relocation might require PLT entry creation. In that case it
is fully supported by the patch. But if the relocation target is a local
symbol we need to use a different expression to calculate the relocation
result. This case is not implemented yet because there is no method to
get know the kind of relocation target in the `relocateOne` routine.
Differential Revision: http://reviews.llvm.org/D16982
llvm-svn: 260424
MIPS 32-bit ABI uses REL relocation record format. We read addends from
relocation destinations right in the MipsTargetInfo::relocateOne
function.
llvm-svn: 260364
This is the function equivalent of a copy relocation.
Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.
The dynamic linker makes sure any shared library uses the plt entry as
the function address.
llvm-svn: 260224
Symbol does not need an entry i the 'global' part of GOT if it cannot be
preempted. So canBePreempted fully satisfies us at least for now.
llvm-svn: 259779
This function is a predicate that a given relocation can be relaxed.
The previous name implied that it returns true if a given relocation
has already been optimized away.
llvm-svn: 259128
In many situations, we don't want to exit at the first error even in the
process model. For example, it is better to report all undefined symbols
rather than reporting the first one that the linker picked up randomly.
In order to handle such errors, we don't need to wrap everything with
ErrorOr (thanks for David Blaikie for pointing this out!) Instead, we
can set a flag to record the fact that we found an error and keep it
going until it reaches a reasonable checkpoint.
This idea should be applicable to other places. For example, we can
ignore broken relocations and check for errors after visiting all relocs.
In this patch, I rename error to fatal, and introduce another version of
error which doesn't call exit. That function instead sets HasError to true.
Once HasError becomes true, it stays true, so that we know that there
was an error if it is true.
I think introducing a non-noreturn error reporting function is by itself
a good idea, and it looks to me that this also provides a gradual path
towards lld-as-a-library (or at least embed-lld-to-your-program) without
sacrificing code readability with lots of ErrorOr's.
http://reviews.llvm.org/D16641
llvm-svn: 259069
In InputSection.cpp it was possible to dereference null.
Had to change signature of relocateTlsOptimize to accept pointer instead of reference.
Differential revision: http://reviews.llvm.org/D16466
llvm-svn: 258508
Some MIPS relocation (for now R_MIPS_GOT16) requires creation of GOT
entries for symbol not included in the dynamic symbol table. They are
local symbols and non-local symbols with 'local' visibility. Local GOT
entries occupy continuous block between GOT header and regular GOT
entries.
The patch adds initial support for handling local GOT entries. The main
problem is allocating local GOT entries for local symbols. Such entries
should be initialized by high 16-bit of the symbol value. In ideal world
there should be no duplicated entries with the same values. But at the
moment of the `Writer::scanRelocs` call we do not know a value of the
symbol. In this patch we create new local GOT entry for each relocation
against local symbol, though we can exhaust GOT quickly. That needs to
be optimized later. When we calculate relocation we know a final symbol
value and request local GOT entry index. To do that we maintain map
between addresses and local GOT entry indexes. If we start to calculate
relocations in parallel we will have to serialize access to this map.
Differential Revision: http://reviews.llvm.org/D16324
llvm-svn: 258388
MIPS ABI has relocations like R_MIPS_JALR which is just a hint for
linker to make some code optimization. Such relocations should not be
handled as a regular ones and lead to say dynamic relocation creation.
The patch introduces new virtual `Target::isHintReloc` method, overrides
it in the `MipsTargetInfo` class and calls it in the `Writer<ELFT>::scanRelocs`
method.
Differential Revision: http://reviews.llvm.org/D16193
llvm-svn: 257798
Fix: Added missed input file.
Initial commit message:
[ELF/AArch64] - Implemented R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 and R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC relocations
* R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 is calculated as Page(G(GTPREL(S+A))) – Page(P), set an ADRP immediate field to bits [32:12] of X; check –2^32 ≤ X < 2^32;
* R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC is calculated as G(GTPREL(S+A)), set an LD offset field to bits [11:3] of X. No overflow check; check that X&7 = 0.
Differential revision: http://reviews.llvm.org/D16117
llvm-svn: 257596
* R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 is calculated as Page(G(GTPREL(S+A))) – Page(P), set an ADRP immediate field to bits [32:12] of X; check –2^32 ≤ X < 2^32;
* R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC is calculated as G(GTPREL(S+A)), set an LD offset field to bits [11:3] of X. No overflow check; check that X&7 = 0.
Differential revision: http://reviews.llvm.org/D16117
llvm-svn: 257588
R_AARCH64_TSTBR14 is calculated as S+A-P,
Set the immediate field of a TBZ/TBNZ instruction to bits [15:2] of X; check -2^15 ≤ X < 2^15
Differential revision: http://reviews.llvm.org/D15824
llvm-svn: 257334
R_AARCH64_CONDBR19 is calculated as S+A-P,
Set the immediate field of a conditional branch instruction to bits [20:2] of X; check -2^20 ≤ X< 2^20.
Afaik there is no document for AARCH64 instruction encoding from official for unknown reason, so
I used gold source code and next link as a reference for implementation: http://kitoslab-eng.blogspot.ru/2012/10/armv8-aarch64-instruction-encoding.html. From which is clear that immediate field of a conditional branch instruction is 5 bits off. That is proved by output which is is equal to gold/bfd now.
Differential revision: http://reviews.llvm.org/D15809
llvm-svn: 257333
R_X86_64_PLT32 is handled in the same way as R_X86_64_PC32 by
relocateOne(), so this function does not seems to be needed.
Without this code, all tests still pass.
http://reviews.llvm.org/D15971
llvm-svn: 257203
All non-trivial relocation decisions need explanations like this
to help readers understand not only how relocations are handled but
why they are handled these ways. This is a start.
llvm-svn: 257119
Summary: This will allow us to remove the AMDGPU support from old ELF.
Reviewers: rafael, ruiu
Differential Revision: http://reviews.llvm.org/D15895
llvm-svn: 257023
The R_MIPS_GPREL16 / R_MIPS_GPREL32 relocations use the following
expressions for calculations:
```
local symbol: S + A + GP0 - GP
global symbol: S + A - GP
GP - Represents the final gp value, i.e. _gp symbol
GP0 - Represents the gp value used to create the relocatable object
```
The GP0 value is taken from the .reginfo data section defined by an object
file. To implement that I keep a reference to `MipsReginfoInputSection`
in the `ObjectFile` class. This reference is used by the
`ObjectFile::getMipsGp0` method to return the GP0 value.
Differential Revision: http://reviews.llvm.org/D15760
llvm-svn: 256416
The patch adds support for R_MIPS_PC16, R_MIPS_PC19_S2, R_MIPS_PC21_S2,
R_MIPS_PC26_S2, R_MIPS_PCHI16, R_MIPS_PCLO16 relocations handling.
llvm-svn: 256172
This relocation is similar to R_*_RELATIVE except that the value used in this relocation is the program address returned by the function, which takes no arguments, at the address of
the result of the corresponding R_*_RELATIVE relocation as specified in the processor-specific ABI. The purpose of this relocation to avoid name lookup for locally defined STT_GNU_IFUNC symbols at load-time.
More info can be found in ifunc.txt from https://sites.google.com/site/x32abi/documents.
Differential revision: http://reviews.llvm.org/D15235
llvm-svn: 256144
R_386_GOTOFF is calculated as S + A - GOT, where:
S - Represents the value of the symbol whose index resides in the relocation entry.
A - Represents the addend used to compute the value of the relocatable field.
GOT - Represents the address of the global offset table.
Differential revision: http://reviews.llvm.org/D15383
llvm-svn: 256143
@indntpoff is similar to @gotntpoff, but for use in position dependent code. While @gotntpoff resolves to GOT slot address relative to the
start of the GOT in the movl or addl instructions, @indntpoff resolves to the
absolute GOT slot address. ("ELF Handling For Thread-Local Storage", Ulrich Drepper).
Differential revision: http://reviews.llvm.org/D15494
llvm-svn: 255884
The `R_MIPS_JALR` is a relocation generated by gcc and gas. This
relocation points to the `jalr` instruction which might be optimized and
converted to the `b` instruction under some conditions.
Now we just ignore this relocation and keep instructions unchanged.
llvm-svn: 255453
R_X86_64_SIZE64/R_X86_64_SIZE32 relocations were introduced in 0.98v of "System V Application Binary Interface x86-64" (http://www.x86-64.org/documentation/abi.pdf).
Calculation for them is Z + A, where:
Z - Represents the size of the symbol whose index resides in the relocation entry.
A - Represents the addend used to compute the value of the relocatable field.
Differential revision: http://reviews.llvm.org/D15335
llvm-svn: 255332
If R_386_PLT32 relocation is applied against symbol that can not be preempted then it can be resolved statically.
Patch implements it for x86 target.
Differential revision: http://reviews.llvm.org/D15376
llvm-svn: 255233
Implement the TLS relocation optimization for 32-bit x86 that is described in
"ELF Handling For Thread-Local Storage" by Ulrich Drepper, chapter 5,
"IA-32 Linker Optimizations". Specifically, this patch implements these
optimizations: LD->LE, GD->IE, GD->LD, and IE->LE.
Differential revision: http://reviews.llvm.org/D15292
llvm-svn: 255103
All relocations, which cannot be handled by the dynamic linker,
cause a linking error "rebuild with -fPIC".
Differential revision: http://reviews.llvm.org/D15193
llvm-svn: 254840
"Ulrich Drepper, ELF Handling For Thread-Local Storage" (5.5 x86-x64 linker optimizations, http://www.akkadia.org/drepper/tls.pdf) shows how GD can be optimized to IE.
This patch implements the optimization.
Differential revision: http://reviews.llvm.org/D15000
llvm-svn: 254713
Main aim of the patch to introduce basic support for TLS access models for x86 target.
Models using @tlsgd, @tlsldm and @gotntpoff are implemented.
Differential revision: http://reviews.llvm.org/D15060
llvm-svn: 254500
Some MIPS relocations including `R_MIPS_HI16/R_MIPS_LO16` use combined
addends. Such addend is calculated using addends of both paired relocations.
Each `R_MIPS_HI16` relocation is paired with the next `R_MIPS_LO16`
relocation. ABI requires to compute such combined addend in case of REL
relocation record format only.
For details see p. 4-17 at
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
This patch implements lookup of the next paired relocation suing new
`InputSectionBase::findPairedRelocLocation` method. The primary
disadvantage of this approach is that we put MIPS specific logic into
the common code. The next disadvantage is that we lookup `R_MIPS_LO16`
for each `R_MIPS_HI16` relocation, while in fact multiple `R_MIPS_HI16`
might be paired with the single `R_MIPS_LO16`. From the other side
this way allows us to keep `MipsTargetInfo` class stateless and implement
later relocation handling in parallel.
This patch does not support `R_MIPS_HI16/R_MIPS_LO16` relocations against
`_gp_disp` symbol. In that case the relocations use a special formula for
the calculation. That will be implemented later.
Differential Revision: http://reviews.llvm.org/D15112
llvm-svn: 254461
ABI specifies the allowed range for these relocations as 2^(n-1) <= X < 2^n.
The patch fixes checks and introduces precise tests for these relocations.
Differential revision: http://reviews.llvm.org/D14957
llvm-svn: 254146
Implements @tlsld (LD to LE) and @tlsgd (GD to LE) optimizations.
Patch does not implement the GD->IE case for @tlsgd.
Differential revision: http://reviews.llvm.org/D14870
llvm-svn: 254101
Patch implements lazy relocations for x86.
One of features of x86 is that executable files and shared object files have separate procedure linkage tables. So patch implements both cases.
Detailed information about instructions used can be found in http://docs.oracle.com/cd/E19620-01/805-3050/chapter6-1235/index.html (search: x86: Procedure Linkage Table).
Differential revision: http://reviews.llvm.org/D14955
llvm-svn: 254098
R_MIPS_CALL16 relocation provides the same result as R_MIPS_GOT16
relocation but does not need to check the result on overflow.
Differential Revision: http://reviews.llvm.org/D14916
llvm-svn: 254092
This patch implements next relocations:
R_386_TLS_LE - Negative offset relative to static TLS (GNU version).
R_386_TLS_LE_32 - Offset relative to static TLS block.
These ones are created when using next code sequences:
* @tpoff - The operator must be used to compute an immediate value. The linker will report
an error if the referenced variable is not defined or it is not code for the executable
itself. No GOT entry is created in this case.
* @ntpoff Calculate the negative offset of the variable it is added to relative to the static TLS block.
The operator must be used to compute an immediate value. The linker will report
an error if the referenced variable is not defined or it is not code for the executable
itself. No GOT entry is created in this case.
Information was found in Ulrich Drepper, ELF Handling For Thread-Local Storage, http://www.akkadia.org/drepper/tls.pdf, (6.2, p76)
Differential revision: http://reviews.llvm.org/D14930
llvm-svn: 254090
https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-26/index.html says:
R_386_GOTPC
Resembles R_386_PC32, except that it uses the address of the global offset table in its calculation. The symbol referenced in this relocation normally is _GLOBAL_OFFSET_TABLE_, which also instructs the link-editor to create the global offset table.
Currently _GLOBAL_OFFSET_TABLE_ has value == zero. And we use GOT address to calculate the relocation. This patch does not changes that. It just removes the method which is used only for x86. So it is close to non functional change.
Differential revision: http://reviews.llvm.org/D14993
llvm-svn: 254088
R_X86_64_GOTTPOFF is not always requires GOT entries. Some relocations can be converted to local ones.
Differential revision: http://reviews.llvm.org/D14713
llvm-svn: 253966
With these relocations, it is now possible to build a simple "hello world"
program for AArch64 Debian.
Differential revision: http://reviews.llvm.org/D14917
llvm-svn: 253957
The content of reserved entries of the .got.plt section is target specific.
In particular, on x86_64 the zero entry holds the address of the .dynamic section,
but on AArch64 the same info is stored in the zero entry of the .got section.
Differential revision: http://reviews.llvm.org/D14703
llvm-svn: 253239
leaq symbol@tlsld(%rip), %rdi
call __tls_get_addr@plt
symbol@tlsld (R_X86_64_TLSLD) instructs the linker to generate a tls_index entry (two GOT slots) in the GOT for the entire module (shared object or executable) with an offset of 0. The symbol for this GOT entry doesn't matter (as long as it's either local to the module or null), and gold doesn't put a symbol in the dynamic R_X86_64_DTPMOD64 relocation for the GOT entry.
All other platforms defined in http://www.akkadia.org/drepper/tls.pdf except for Itanium use a similar model where global and local dynamic GOT entries take up 2 contiguous GOT slots, so we can handle this in a unified manner if we don't care about Itanium.
While scanning relocations we need to identify local dynamic relocations and generate a single tls_index entry in the GOT for the module and store the address of it somewhere so we can later statically resolve the offset for R_X86_64_TLSLD relocations. We also need to generate a R_X86_64_DTPMOD64 relocation in the RelaDyn relocation section.
This implementation is a bit hacky. It side steps the issue of GotSection and RelocationSection only handling SymbolBody entries by relying on a specific relocation type. The alternative to this seemed to be completely rewriting how GotSection and RelocationSection work, or using a different hacky signaling method.
llvm-svn: 252682
Rafael Espindola