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
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
Currently the freebsd early boot code fails to link. The issue reduces
to 16 bit code at position 0x7000 wanting to jump to position
0x9000. That is represented in the .o file as a relocation with no
symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip
after the current instruction for jumps).
If the addend is interpreted as signed (it should), it is -28674. In a
32 bit architecture, that is the address 0xffff8ffe. To get there from
0x7000 we have to add 4294909950 (too big) or subtract 57346 (too
small). We then produce an error.
What lld is missing is the fact that at runtime this will actually be
a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the
correct result in 16 bits (-28674).
Since we have a 16 bit addend and a 16 bit PC, the relocation can move
the PC to any 16 bit address and that is the only thing we really need
to check: if the address we are pointing to fits in 16 bits. This is
unfortunately hard to do since we have to delay subtracting the PC and
if we want to do that outside of Target.cpp, we have to move the
overflow check out too. An incomplete patch that tries to do that is
at https://reviews.llvm.org/D34070
This patch instead just relaxes the check. Since the value we have is
the destination minus the PC and the PC is 16 bits, it should fit in
17 bits if the destination fits in 16 too.
bfd had a similar issue for some time and got a similar fix:
https://sourceware.org/ml/binutils/2005-08/msg00001.html
llvm-svn: 305135
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
Before InputSectionBase had an OutputSection pointer, but that was not
always valid. For example, if it was a merge section one actually had
to look at MergeSec->OutSec.
This was brittle and caused bugs like the one fixed by r304260.
We now have a single Parent pointer that points to an OutputSection
for InputSection, but to a SyntheticSection for merge sections and
.eh_frame. This makes it impossible to accidentally access an invalid
OutSec.
llvm-svn: 304338
This change adds support for the R_ARM_SBREL32 relocation. The relocation
is a base relative relocation that is produced by clang/llvm when -frwpi
is used. The use case for the -frwpi option is position independent data
for embedded systems that do not have a GOT. With -frwpi all data is
accessed via an offset from a base register (usually r9), where r9 is set
at run time to where the data has been loaded. The base of the data is
known as the static base.
The ARM ABI defines the static base as:
B(S) is the addressing origin of the output segment defining the symbol S.
The origin is not required to be the base address of the segment. For
simplicity we choose to use the base address of the segment.
The ARM procedure call standard only defines a read write variant using
R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative
offsets from the code, this is implemented in clang as -fropi.
Fixes PR32924
Differential Revision: https://reviews.llvm.org/D33280
llvm-svn: 303337
This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."
Because DF_STATIC_TLS does not look to be used by glibc or anything else.
llvm-svn: 302884
Both gold and bfd restrict that one:
ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be
used when making a shared object; recompile with -fPIC
ld.gold: error: test.o: unsupported reloc 23 against global symbol var
What looks reasonable because it is 32 bit one. Patch do the same.
Differential revision: https://reviews.llvm.org/D33100
llvm-svn: 302881
When compiling LLD using GCC 7 it reports warnings like:
"warning: this statement may fall through [-Wimplicit-fallthrough=]"
LLVM has LLVM_FALLTHROUGH macro which can be used to avoid such warnings.
Together with D33036 this patch fixes them.
Differential revision: https://reviews.llvm.org/D32907
llvm-svn: 302666
This is PR32437.
DF_STATIC_TLS
If set in a shared object or executable, this flag instructs the
dynamic linker to reject attempts to load this file dynamically.
It indicates that the shared object or executable contains code
using a static thread-local storage scheme. Implementations need
not support any form of thread-local storage.
Patch checks if IE/LE relocations were used to check if code uses
static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D32354
llvm-svn: 302414
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
This code was not used because of
handleARMTlsRelocation and handleMipsTlsRelocation methods that are called
for these platforms instead of regular TLS code.
Differential revision: https://reviews.llvm.org/D32355
llvm-svn: 301414
This relocation type has an implicit addend. Account for it when
processing the relocation. Add an offset to an existing test to ensure
it gets processed correctly.
Fixes PR32634.
Differential Revision: https://reviews.llvm.org/D32336
llvm-svn: 301207
Replace addModuleReloc with AddTlsReloc so that we can use it for both the
module relocation and the offset relocation.
Differential Revision: https://reviews.llvm.org/D31751
llvm-svn: 300192
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
Previously, the code we set to our .plt entries expected that .got
and .got.plt are consecutive in the virtual address space.
Since %ebx points to the last entry of .got for position-independent
code, it assumed that .got is accessible with small negative
displacements and .got.plt are accessible with small positive
displacements.
That assumption was simply wrong. We don't impose any restrictions on
relative layout of .got and .got.plt. As a result, the control is
transferred to a bogus address from .plt at runtime, which resulted in
segfaults.
This patch removes that wrong assumption. We still assume that .got.plt
has a fixed relative address to .got, but we no longer assume that they
are consecutive in memory.
With this change, a "hello world" program compiled with -fPIC works.
Fixes https://bugs.llvm.org/show_bug.cgi?id=31332.
Differential Revision: https://reviews.llvm.org/D31682
llvm-svn: 299553
The patch introduces two new relocations expressions R_MIPS_GOT_GP and
R_MIPS_GOT_GP_PC. The first one represents a current value of `_gp`
pointer and used to calculate relocations against the `__gnu_local_gp`
symbol. The second one represents the offset between the beginning of
the function and the `_gp` pointer's value.
There are two motivations for introducing new expressions:
- It's better to keep all non-trivial relocation calculations in the
single place - `getRelocTargetVA` function.
- Relocations against both `_gp_disp` and `__gnu_local_gp` symbols
depend on the `_gp` value. It's a magical value points to the "middle"
of GOT. Now all relocations use a common `_gp` value. But in fact,
under some conditions each input file might require its own `_gp`
value. I'm going to implement it in the future patches. So it's
better to make `MipsGotSection` responsible for calculation of
the `_gp` value.
llvm-svn: 298306
We had a few Config member functions that returns configuration values.
For example, we had is64() which returns true if the target is 64-bit.
The return values of these functions are constant and never change.
This patch is to compute them only once to make it clear that they'll
never change.
llvm-svn: 298168
The list of all input sections was defined in SymbolTable class for a
historical reason. The list itself is not a template. However, because
SymbolTable class is a template, we needed to pass around ELFT to access
the list. This patch moves the list out of the class so that it doesn't
need ELFT.
llvm-svn: 296309
With the current design an InputSection is basically anything that
goes directly in a OutputSection. That includes plain input section
but also synthetic sections, so this should probably not be a
template.
llvm-svn: 295993
We shouldn't report an error for R_*_NONE relocs since we're emitting
them when writing relocations to discarded sections.
Differential Revision: https://reviews.llvm.org/D30279
llvm-svn: 295936
If target of R_MIPS_GOT16 relocation is a local symbol its addend
is high 16 bits of complete addend. To calculate a final value, the addend
of this relocation is read, shifted to the left and combined with addend
of paired R_MIPS_LO16 relocation. To save updated addend when the linker
produces a relocatable output, we need to store high 16 bits of the
addend's value. It is different from the case of writing the relocation
result when the linker saves a 16-bit GOT index as-is.
llvm-svn: 295159
Peter Smith