When parsing linker scripts, LLD previously started with a '.' value of 0,
regardless of the internal default image base for the target, and regardless of
switches such as --image-base. It seems reasonable to use a different image base
value when using linker scripts and --image-base is specified, since otherwise the
switch has no effect. This change does this, as well as removing unnecessary
initialisation of Dot where it is not used.
The default image base should not be used when processing linker
scripts, because this will change the behaviour for existing linker script users,
and potentially result in invalid output being produced, as a subsequent assignment
to Dot could move the location counter backwards. Instead, we maintain the existing
behaviour of starting from 0 if --image-base is not specified.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D38360
llvm-svn: 315293
In preparation for range extension thunks introduce a function that will
check whether a branch identified by a relocation type at a source address
can reach a destination.
For targets where range extension thunks are not supported the function will
return true as it is not expected that branches are out of range. An
implementation has been provided for ARM.
Differential Revision: https://reviews.llvm.org/D34690
llvm-svn: 308188
Add support for the most common SPARC relocations.
Make DT_PLTGOT point to the PLT on SPARC.
Mark the PLT as executable on SPARC.
This adds a basic test that creates a SPARV9 executable
that invokes the exit system call on OpenBSD.
Patch by Mark Kettenis.
Differential Revision: https://reviews.llvm.org/D34618
llvm-svn: 306565
On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - .
and produce a relocation that can be processed without needing to know the
value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM
gcc produces R_ARM_BASE_PREL but clang produces the more general
R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation
correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of
the GOT or end of the GOT dependent on architecture..
If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this
change will not be necessary for new objects. However there may still be
old objects and versions of clang.
Differential Revision: https://reviews.llvm.org/D34355
llvm-svn: 306282
Target.cpp contains code for all the targets that LLD supports. It was
simple and easy, but as the number of supported targets increased,
it got messy.
This patch splits the file into per-target files under ELF/arch directory.
Differential Revision: https://reviews.llvm.org/D34222
llvm-svn: 305565
This feels a bit hackish, but I think it is still an improvement.
The way a tls address is computed in the various architectures is not
that different. For example, for local dynamic we need the base of the
tls (R_TLSLD or R_TLSLD_PC), and the offset of that particular symbol
(R_ABS).
Given the similarity, we can just use the expressions instead of
having two additional target hooks.
llvm-svn: 302279
Previously we silently produced broken output for R_386_GOT32X/R_386_GOT32
relocations if they were used to compute the address of the symbol’s global
offset table entry without base register when position-independent code is disabled.
Situation happened because of recent ABI changes. Released ABI mentions that
R_386_GOT32X can be calculated in a two different ways (so we did not follow ABI here
before this patch), but draft ABI also mentions R_386_GOT32 relocation here.
We should use the same calculations for both relocations.
Problem is that we always calculated them as G + A - GOT (offset from end of GOT),
but for case when PIC is disabled, according to i386 ABI calculation should be G + A,
what should produce just an address in GOT finally.
ABI: https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-draft.pdf (p36, p60).
llvm-svn: 299812
Executable sections should not be padded with zero by default. On some
architectures, 0x00 is the start of a valid instruction sequence, so can confuse
disassembly between InputSections (and indeed the start of the next InputSection
in some situations). Further, in the case of misjumps into padding, padding may
start to be executed silently.
On x86, the "0xcc" byte represents the int3 trap instruction. It is a single
byte long so can serve well as padding. This change switches x86 (and x86_64) to
use this value for padding in executable sections, if no linker script directive
overrides it. It also puts the behaviour into place making it easy to change the
behaviour of other targets when desired. I do not know the relevant instruction
sequences for trap instructions on other targets however, so somebody should add
this separately.
Because the old behaviour simply wrote padding in the whole section before
overwriting most of it, this change also modifies the padding algorithm to write
padding only where needed. This in turn has caused a small behaviour change with
regards to what values are written via Fill commands in linker scripts, bringing
it into line with ld.bfd. The fill value is now written starting from the end of
the previous block, which means that it always starts from the first byte of the
fill, whereas the old behaviour meant that the padding sometimes started mid-way
through the fill value. See the test changes for more details.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D30886
Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32227
llvm-svn: 299635
Relocations are abstracted as platform-independent R_TLS_* relocations,
so we don't need to check platform-specific ones to see if a relocation
is TLS GD.
llvm-svn: 299614
If relocations don't have addends, addends are embedded in operands.
getImplicitAddend is a function to read addends. Addends can be
negative numbers, so the return type of the function should be a
signed integer type.
llvm-svn: 294253
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.
Differential revision: https://reviews.llvm.org/D29327
llvm-svn: 293757
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
Differential Revision: https://reviews.llvm.org/D29129
llvm-svn: 293283
Mapping symbols allow a mapping symbol aware disassembler to
correctly disassemble the PLT when the code immediately prior to the
PLT is Thumb.
To implement this we add a function to add symbols with local
binding to be defined in SyntheticSymbols.
Differential Revision: https://reviews.llvm.org/D28956
llvm-svn: 293044
A necessary first step towards range extension thunks is to delay
the creation of thunks until the layout of InputSections within
OutputSections has been done.
The change scans the relocations directly from InputSections rather
than looking in the ELF File the InputSection came from. This will
allow a future change to redirect the relocations to symbols defined
by Thunks rather than indirect when resolving relocations.
A side-effect of moving ThunkCreation is that the OutSecOff of
InputSections may change in an OutputSection that contains Thunks.
In well behaved programs thunks are not in OutputSections with
dynamic relocations.
Differential Revision: https://reviews.llvm.org/D28811
llvm-svn: 292359
The i386 glibc ld.so expects the .got.slot entry that is relocated by a
R_386_IRELATIVE relocation to point directly at the ifunc resolver and
not the address of the PLT entry + 6 (thus entering the lazy resolver).
This is also the case for ARM and I suspect it is because these use REL
relocations and can't use the addend field to store the address of the
ifunc resolver. If the lazy resolver is used we get an error message
stating that only R_386_JUMP_SLOT is supported.
As ARM and i386 share the same code, I've removed the ARM specific test
and added a writeIgotPlt() function that by default calls writeGotPlt().
ARM and i386 override this to write the address of the ifunc resolver.
Differential Revision: https://reviews.llvm.org/D27581
llvm-svn: 289198
Offset between beginning of a .got section and _gp symbols used in MIPS
GOT relocations calculations. Usually the expression looks like
VA + Offset - GP, where VA is the .got section address, Offset - offset
of the GOT entry, GP - offset between .got and _gp. Also there two "magic"
symbols _gp_disp and __gnu_local_gp which hold the offset mentioned above.
These symbols might be referenced by MIPS relocations.
Now the linker always defines _gp symbol and uses hardcoded value for
its initialization. So offset between .got and _gp is 0x7ff0. The _gp_disp
and __gnu_local_gp defined if required and initialized by 0x7ff0.
In fact that is not correct because _gp symbol might be defined by a linker
script and holds arbitrary value. In that case we need to use this value
in relocation calculation and initialize _gp_disp and __gnu_local_gp
properly.
The patch fixes the problem and completes fixing the bug #30311.
https://llvm.org/bugs/show_bug.cgi?id=30311
Differential revision: https://reviews.llvm.org/D27036
llvm-svn: 287832
We have different functions to stringize objects to construct
error messages. For InputFile, we have getFilename, and for
InputSection, we have getName. You had to memorize them.
I think this is the case where the function overloading comes in handy.
This patch defines toString() functions that are overloaded for all these
types, so that you just call it in error().
Differential Revision: https://reviews.llvm.org/D27030
llvm-svn: 287787
Align to the large page size (known as a superpage or huge page).
FreeBSD automatically promotes large, superpage-aligned allocations.
Differential Revision: https://reviews.llvm.org/D27042
llvm-svn: 287782
We will need to do something like this to support range extension
thunks since that process is iterative.
Doing this also has the advantage that when doing the regular
relocation scan the offset in the output section is known and we can
just store that. This reduces the number of times we have to run
getOffset and I think will allow a more specialized .eh_frame
representation.
By itself this is already a performance win.
firefox
master 7.295045737
patch 7.209466989 0.98826892235
chromium
master 4.531254468
patch 4.509221804 0.995137623774
chromium fast
master 1.836928973
patch 1.823805241 0.992855612714
the gold plugin
master 0.379768791
patch 0.380043405 1.00072310839
clang
master 0.642698284
patch 0.642215663 0.999249070657
llvm-as
master 0.036665467
patch 0.036456225 0.994293213284
the gold plugin fsds
master 0.40395817
patch 0.404384555 1.0010555177
clang fsds
master 0.722045545
patch 0.720946135 0.998477367518
llvm-as fsds
master 0.03292646
patch 0.032759965 0.994943428477
scylla
master 3.427376378
patch 3.368316181 0.98276810292
llvm-svn: 276146
Patch by H.J Lu.
For x86-64 psABI, the entry size of .got and .got.plt sections is 8
bytes for both LP64 and ILP32. Add GotEntrySize and GotPltEntrySize
to ELF target instead of using size of ELFT::uint. Now we can generate
a simple working x32 executable.
Differential Revision: http://reviews.llvm.org/D22288
llvm-svn: 275301
Config members are named after corresponding command line options.
This patch renames VAStart ImageBase so that they are in line with
--image-base.
Differential Revision: http://reviews.llvm.org/D22277
llvm-svn: 275298
Only MipsThunk were using the function, and the way how it wrote
thunk contents was different from ARM thunks. This patch makes
them consistent.
llvm-svn: 274997
The TinyPtrVector of const Thunk<ELFT>* in InputSections.h can cause
build failures on certain compiler/library combinations when Thunk<ELFT>
is not a complete type or is an abstract class. Fixed by making Thunk<ELFT>
non Abstract.
type or is an abstract class
llvm-svn: 274863
Generalise the Mips LA25 Thunk code and implement ARM and Thumb
interworking Thunks.
- Introduce a new module Thunks.cpp to store the Target Specific Thunk
implementations.
- DefinedRegular and Shared have a ThunkData field to record Thunk.
- A Target can have more than one type of Thunk.
- Support PC-relative calls to Thunks.
- Support Thunks to PLT entries.
- Existing Mips LA25 Thunk code integrated.
- Support for ARMv7A interworking Thunks.
Limitations:
- Only one Thunk per SymbolBody, this is sufficient for all currently
implemented Thunks.
- ARM thunks assume presence of V6T2 MOVT and MOVW instructions.
Differential revision: http://reviews.llvm.org/D21891
llvm-svn: 274836
PltZero (or PLT[0]) was an appropriate name for the little code
we have at beginning of the PLT section when we only supported x86
since the code for x86 just fits in the first PLT slot.
It's not the case anymore. The code for ARM64 occupies first two
slots, so PltZero spans PLT[0] and PLT[1], for example.
This patch renames it to avoid confusion.
llvm-svn: 272913
For ARM and MIPS, we don't need to call this function.
This patch passes a symbol instead of a PLT entry address
so that the target handler can call it if necessary.
llvm-svn: 272910
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
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 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
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
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
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
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
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
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
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
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
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
James Henderson