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
Patch makes addends for addends of R_386_8, R_386_16 relocations
be sign extended.
The same we did earlier for PC ones,
currenly LLD fails to link linux kernel,
reporting relocation out of range because of this.
Differential revision: https://reviews.llvm.org/D29714
llvm-svn: 295052
Previously we did not do that. For example, for R_386_PC8,
0xFF addend was not treated as 0xFFFFFFFF(-1),
but was 0x000000FF.
Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation
overflow as a result.
Differential revision: https://reviews.llvm.org/D29490
llvm-svn: 294289
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
It is not clear what we should do when overflow occurs for these
relocations because the relocations are not an official part of
the i386 psABI. But checking for overflow is generally a good to do
and is consistent with other relocations such as R_X86_64_8.
llvm-svn: 293683
Our reporting for that case was just like:
ld.lld: error: do not know how to handle relocation 'R_386_PC8' (23)
It did not give any information about error location.
Patch adds filename to error.
Differential revision: https://reviews.llvm.org/D29282
llvm-svn: 293640
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
Although this relocation type is not part of the x86-64 psABI, I intend to
use it internally as part of the ThinLTO implementation.
Differential Revision: https://reviews.llvm.org/D28841
llvm-svn: 292330
The same we did for x86 earlier:
list supported relocations explicitly and error out on unknown.
Differential revision: https://reviews.llvm.org/D28564
llvm-svn: 291751
We had an error when met this relocation
after latest changes aboult listing
x86 relocations explicitly.
Since we support R_X86_64_NONE,
and GNU ld supports R_386_NONE,
it seems reasonable to have.
Differential revision: https://reviews.llvm.org/D28552
llvm-svn: 291672
Previously some value was returned by default for relocations by getRelExpr(),
even if relocation actually was not supported.
This is orthogonal alternative to D28094.
Instead of implementing probably useless R_386_PC8/R_386_8 relocations,
this patch uses them in a testcase to demonstrate what happens
when LLD mets unsupported relocations.
Patch passes all testcases and changes logic only for x86.
Differential revision: https://reviews.llvm.org/D28516
llvm-svn: 291658
In a shared library an undefined symbol is implicitly imported. If the
symbol is called as a function a PLT entry is generated for it. When the
caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT
entries are in ARM state.
This change allows undefined symbols to have thunks in the same way that
shared symbols may have thunks.
llvm-svn: 290951
This is last known noticable fatal() in target.cpp.
We also have other ones for unknown relocations or
creating unknown targets, but that one can be just error I think.
Used yaml2obj to generate test.
Differential revision: https://reviews.llvm.org/D28049
llvm-svn: 290335
We probably would want to avoid fatal() if we can in context of librarification,
but for me reason of that patch is to help D27900 go.
D27900 changes errors reporting to something like
error: text1
note: text2
note: text3
where hint used to provide additional information about location. In that case
I can't just call fatal() because user will not see notes after that what adds additional complication to handle.
So It is good to switch fatal() to error() where it is possible.
Also it adds testcase with broken relocation number.
Previously we did not have any, It checks that error() instead of fatal() works fine.
Differential revision: https://reviews.llvm.org/D27973
llvm-svn: 290239
I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.
Differential Revision: https://reviews.llvm.org/D27819
llvm-svn: 290062
When compiling -fpie and linking with the --pie option the R_ARM_GOTBREL
relocation to D is resolved by writing the value of D into the .got slot
and emitting an R_ARM_RELATIVE relocation for it.
This changes adds the R_ARM_RELATIVE relocation to the switch in
relocateOne() so we can process the GotSection relocation to write the
value of the variable as well as emitting the dynamic relocation.
Differential revision: https://reviews.llvm.org/D27678
llvm-svn: 289527
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
These MIPS specific symbols should be global because in general they can
have an arbitrary value. By default this value is a fixed offset from .got
section.
This patch adds more checks to the mips-gp-local.s test case but marks
it as XFAIL because LLD does not allow redefinition of absolute symbols
value by a linker script. This should be fixed by D27276.
Differential revision: https://reviews.llvm.org/D27524
llvm-svn: 289025
This patch refactor how to apply the R_AARCH64_LDST{8,16,32,64,128}_ABS_NC
relocations by adding a new function to correct extract the bits expected
by each relocation. This make is explicit which are the bits range expected
and simplify the code to mask and shift the deriable values.
It also fixes the R_AARCH64_LDST128_ABS_LO12_NC mask, although in pratice
the mask/shift always returns a 16 bytes aligned value.
Checked on AArch64 and with test-suite.
llvm-svn: 288921
The relocation R_AARCH64_LDST16_ABS_LO12_NC should set a ld/st
immediate value to bits [11:1] not [11:2]. This patches fixes it
and adds a testcase for regression.
With this fix all the faulty tests on test-suite (clavm, lencod,
and trimaran) pass.
llvm-svn: 288670
A program or object file using R_386_8, R_386_16, R_386_PC16 or R_386_PC8
relocations is not conformant to latest ABI. The R_386_16, and R_386_8
relocations truncate the computed value to 16 - bits and 8 - bits
respectively. R_386_PC16 and R_386_16 are used by some
applications, for example by FreeBSD loaders.
Previously we did not take addend in account for these relocation,
counting it as 0, what is wrong and was a reason of hangs.
This patch needed for example for FreeBSD pmbr (protective mbr).
Differential revision: https://reviews.llvm.org/D27303
llvm-svn: 288581
It looks like the way dtrace works is
* The user creates .o files that reference magical symbol names.
* dtrace reads those files, collecs the info it needs and changes the
relocation to R_X86_64_NONE expecting the linker to ignore them.
llvm-svn: 288485
The module index dynamic relocation R_ARM_DTPMOD32 is always 1 for an
executable. When static linking and when we know that we are not a shared
object we can resolve the module index relocation statically.
The logic in handleNoRelaxTlsRelocation remains the same for Mips as it
has its own custom GOT writing code. For ARM we add the module index
relocation to the GOT when it can be resolved statically.
In addition the type of the RelExpr for the static resolution of TlsGotRel
should be R_TLS and not R_ABS as we need to include the size of
the thread control block in the calculation.
Addresses the TLS part of PR30218.
Differential revision: https://reviews.llvm.org/D27213
llvm-svn: 288153
Right now we just remember a SymbolBody for each got entry and
duplicate a bit of logic to decide what value, if any, should be
written for that SymbolBody.
With ARM there will be more complicated values, and it seems better to
just use the relocation code to fill the got entries. This makes it
clear that each entry is filled by the dynamic linker or by the static
linker.
llvm-svn: 288107
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
MIPS GOT handling is very different from other targets so it is better
to keep the code in the separatre section class MipsGotSection. This
patch introduces the new section and moves all MIPS specific code from
GotSection to the new class. I did not rename fields and methods in the
MipsGotSection class to reduce the diff and plan to do that by the
separate commit.
Differential revision: https://reviews.llvm.org/D26733
llvm-svn: 287150
This patch introduces the following changes:
- DynamicSection now inherits InputSection<ELFT> and was moved
to SyntheticSections.h/.cpp.
- Link and Entsize fields of DynamicSection are propagated to
its output section
- In<ELFT>::SyntheticSections was removed.
- Finalization of synthetic sections was removed from
OutputSection<ELFT>::finalize. Now finalizeSyntheticSections is
used instead.
Differential revision: https://reviews.llvm.org/D26603
llvm-svn: 286950
This is similar to what was done for InputSection.
With this the various fields are stored in host order and only
converted to target order when writing.
llvm-svn: 286327
In short the patch introduces support for linking object file conform
MIPS N32 ABI [1]. This ABI is similar to N64 ABI but uses 32-bit
pointer size.
The most non-trivial requirement of this ABI is one more relocation
packing format. N64 ABI puts multiple relocation type into the single
relocation record. The N32 ABI uses series of successive relocations
with the same offset for this purpose. In this patch, new function
`mergeMipsN32RelTypes` handle this case and "convert" N32 relocation to
the N64 relocation so the rest of the code keep unchanged.
For now, linker does not support series of relocations applied to sections
without SHF_ALLOC bit. Probably later I will add the support or insert
some sort of assert into the `relocateNonAlloc` routine to catch this
case.
[1] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/MIPS-N32-ABI-Handbook.pdf
Differential revision: https://reviews.llvm.org/D26298
llvm-svn: 286052
An undefined weak reference is given an address of 0 this will
incorrectly trigger the creation of a Thumb to ARM interworking Thunk
if there is a Thumb branch instruction to the symbol. This results in
an error as Thunks only make sense to defined or shared symbols.
We prevent this by detecting an undefined symbol and not creating a thunk
for it.
Differential Revision: https://reviews.llvm.org/D26239
llvm-svn: 285896
Some MIPS relocations used to access GOT entries are able to manipulate
16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle
32-bit indexes. 16-bit relocations are generated by default. The 32-bit
relocations are generated by -mxgot flag passed to compiler. Usually
these relocation are not mixed in the same code but files like crt*.o
contain 16-bit relocations so even if all "user's" code compiled with
-mxgot flag a few 16-bit relocations might come to the linking phase.
Now LLD does not differentiate local GOT entries accessed via a 16-bit
and 32-bit indexes. That might lead to relocation's overflow if 16-bit
entries are allocated to far from the beginning of the GOT.
The patch introduces new "part" of MIPS GOT dedicated to the local GOT
entries accessed by 32-bit relocations. That allows to put local GOT
entries accessed via a 16-bit index first and escape relocation's overflow.
Differential revision: https://reviews.llvm.org/D25833
llvm-svn: 284809
This is needed for the following case (OpenCL example):
__global int Var = 0;
__global int* Ptr[] = {&Var};
...
Differential Revision: https://reviews.llvm.org/D25815
llvm-svn: 284764
Rafael Espindola