Now reportUndefined only has to look at Config->UnresolvedSymbols and
the symbol. getUnresolvedSymbolOption does all the hard work of
mapping options like -shared and -z defs to one of the
UnresolvedPolicy enum entries.
The critical fix is that now "-z defs --warn-unresolved-symbols" only
warns.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@293290 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@293283 91177308-0d34-0410-b5e6-96231b3b80d8
Include removal of call to getThunkExpr() as it has already been
called and recorded by scanRelocs()
Cleanup suggestions by Rafael.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@292614 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@292359 91177308-0d34-0410-b5e6-96231b3b80d8
When reserving copy relocation space for a shared symbol, scan the DSO's
program headers to see if the symbol is in a read-only segment. If so,
reserve space for that symbol in a new synthetic section named .bss.rel.ro
which will be covered by the relro program header.
This fixes the security issue disclosed on the binutils mailing list at:
https://sourceware.org/ml/libc-alpha/2016-12/msg00914.html
Differential Revision: https://reviews.llvm.org/D28272
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291524 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64 TLSDESC for local symbol in shared objects are implemented in a
arch specific manner where the TLSDESC dynamic relocation addend is the
symbol VM inside the TLS block. For instance, with a shared library
created from the code:
--
static __thread int32_t x1;
static __thread int64_t x2;
int32_t foo1 (int32_t x)
{
x1 += x;
return x;
}
int64_t foo2 (int64_t x)
{
x2 += x;
return x;
}
--
The dynamic relocation should be create as:
Relocations [
Section (N) .rela.dyn {
<Address1> R_AARCH64_TLSDESC - 0x0
<Address2> R_AARCH64_TLSDESC - 0x8
}
]
Where 0x0 addend in first dynamic relocation is the address of 'x1'
in TLS block and '0x8' is the address of 'x2'.
Checked against test-suite on aarch64-linux-gnu.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290099 91177308-0d34-0410-b5e6-96231b3b80d8
This change introduces new synthetic sections IpltSection, IgotPltSection
that represent the ifunc entries that would previously have been put in
the PltSection and the GotPltSection. The separation makes sure that
the R_*_IRELATIVE relocations are placed after the non R_*_IRELATIVE
relocations, which permits ifunc resolvers to know that the .got.plt
slots will be initialized prior to the resolver being called.
A secondary benefit is that for ARM we can move the IgotPltSection and its
dynamic relocations to the .got and .rel.dyn as the ARM glibc expects all
the R_*_IRELATIVE relocations to be in the .rel.dyn
Differential revision: https://reviews.llvm.org/D27406
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@289045 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@289025 91177308-0d34-0410-b5e6-96231b3b80d8
For preemptable symbols the dynamic linker does all the work. Trying
to compute the addend is at best wasteful and can also lead to crashes
in cases of programs that uses tls but doesn't define any tls
variables.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@288803 91177308-0d34-0410-b5e6-96231b3b80d8
In various places in LLD's hot loops, we have expressions of the form
"E == R_FOO || E == R_BAR || ..." (E is a RelExpr).
Some of these expressions are quite long, and even though they usually go just
a very small number of ways and so should be well predicted, they can still
occupy branch predictor resources harming other parts of the code, or they
won't be predicted well if they overflow branch predictor resources or if the
branches are too dense and the branch predictor can't track them all (the
compiler can in theory avoid this, at a cost in text size). And some of these
expressions are so large and executed so frequently that even when
well-predicted they probably still have a nontrivial cost.
This speedup should be pretty portable. The cost of these simple bit tests is
independent of:
- the target we are linking for
- the distribution of RelExpr's for a given link (which can depend on how the
input files were compiled)
- what compiler was used to compile LLD (it is just a simple bit test;
hopefully the compiler gets it right!)
- adding new target-dependent relocations (e.g. needsPlt doesn't pay any extra
cost checking R_PPC_PLT_OPD on x86-64 builds)
I did some rough measurements on clang-fsds and this patch gives over about 4%
speedup for a regular -O1 link, about 2.5% for -O3 --gc-sections and over 5%
for -O0. Sorry, I don't have my current machine set up for doing really
accurate measurements right now.
This also is just a bit cleaner. Thanks for Joerg for suggesting for
this approach.
Differential Revision: https://reviews.llvm.org/D27156
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@288314 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@288153 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@288107 91177308-0d34-0410-b5e6-96231b3b80d8
The function was used only within Relocations.cpp, but now we are
using it in many places, so this patch moves it to a file that fits
to the functionality.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@287943 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@287787 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we stored offsets in string tables to symbols, so
you needed to pass a string table to get a symbol name. This patch
stores const char pointers instead to eliminate the need to pass
a string table.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@287737 91177308-0d34-0410-b5e6-96231b3b80d8
Jack Andersen
Rafael Espindola
Peter Smith
Peter Collingbourne
Adhemerval Zanella
Simon Atanasyan
Sean Silva
Rui Ueyama
Eugene Leviant