A section was passed to getRelExpr just to create an error message.
But if there's an invalid relocation, we would eventually report it
in relocateOne. So we don't have to pass a section to getRelExpr.
llvm-svn: 315552
We were using uint32_t as the type of relocation kind. It has a
readability issue because what Type really means in `uint32_t Type`
is not obvious. It could be a section type, a symbol type or a
relocation type.
Since we do not do any arithemetic operations on relocation types
(e.g. adding one to R_X86_64_PC32 doesn't make sense), it would be
more natural if they are represented as enums. Unfortunately, that
is not doable because relocation type definitions are spread into
multiple header files.
So I decided to use typedef. This still should be better than the
plain uint32_t because the intended type is now obvious.
llvm-svn: 315525
"Commands" was ambiguous because in the linker script, everything is
a command. We used to handle only SECTIONS commands, and at the time,
it might make sense to call them the commands, but it is no longer
the case. We handle not only SECTIONS but also MEMORY, PHDRS, VERSION,
etc., and they are all commands.
llvm-svn: 315409
This fixes pr34301.
As the bug points out, we want to keep some relocations with undefined
weak symbols. This means that we cannot always claim that these
symbols are not preemptible as we do now.
Unfortunately, we cannot also just always claim that they are
preemptible. Doing so would, for example, cause us to try to create a
plt entry when we don't even have a dynamic symbol table.
What almost works is to say that weak undefined symbols are
preemptible if and only if we have a dynamic symbol table. Almost
because we don't want to fail the build trying to create a copy
relocation to a weak undefined.
llvm-svn: 313372
The patch implements initial support of microMIPS code linking:
- Handle microMIPS specific relocations.
- Emit both R1-R5 and R6 microMIPS PLT records.
For now linking mixed set of regular and microMIPS object files is not
supported. Also the patch does not handle (setup and clear) the
least-significant bit of an address which is utilized as the ISA mode
bit and allows to make jump between regular and microMIPS code without
any thunks.
Differential revision: https://reviews.llvm.org/D37335
llvm-svn: 313028
Replace OutputSection *Cmd to OutputSection *OS. The Commands vector was
moved to OutputSection but the names of the variables were not. This patch
changes the names to match.
Differential Revision: https://reviews.llvm.org/D37627
llvm-svn: 313015
This is PR32429.
We did not mention -fPIC in error about producing dynamic relocation
in readonly segment before. Patch changes that.
Differential revision: https://reviews.llvm.org/D36874
llvm-svn: 312003
Currently LLD reads the R_MIPS_HI16's addends in the `computeMipsAddend`
function, the R_MIPS_LO16's addends in both `computeMipsAddend` and
`getImplicitAddend` functions. This patch moves reading all addends to
the `getImplicitAddend` function. As a side effect it fixes a "paired"
HI16/LO16 addend calculation if "LO16" part of a pair is not found.
llvm-svn: 311711
This is probably a small optimization, but the main motivation is
having a way of fixing pr34053 that doesn't require a hash lookup in
isPreempitible.
llvm-svn: 310602
With this Symbol has the same size as before, but DefinedRegular goes
from 72 to 64 bytes.
I also find this a bit easier to read. There are fewer places
initializing File for example.
This has a small but measurable speed improvement on all tests (1%
max).
llvm-svn: 310142
Reviewing another change I noticed that we use "getSymbols" to mean
different things in different files. Depending on the file it can
return
ArrayRef<StringRef>
ArrayRef<SymbolBody*>
ArrayRef<Symbol*>
ArrayRef<Elf_Sym>
With this change it always returns an ArrayRef<SymbolBody*>. The other
functions are renamed getELFsyms() and getSymbolNames().
Note that we cannot return ArrayRef<Symbol*> instead of
ArreyRef<SymbolBody*> because local symbols have a SymbolBody but not
a Symbol.
llvm-svn: 309840
This is a bit of a hack, but it is *so* convenient.
Now that we create synthetic linker scripts when none is provided, we
always have to handle paired OutputSection and OutputsectionCommand and
keep a mapping from one to the other.
This patch simplifies things by merging them and creating what used to
be OutputSectionCommands really early.
llvm-svn: 309311
Previously we handled this option implicitly, only
for infering unresolved symbols handling policy.
ld man says: "--noinhibit-exec Retain the executable
output file whenever it is still usable",
and we may want to handle other cases too.
Differential revision: https://reviews.llvm.org/D35793
llvm-svn: 309091
This change permits there to be more than one thunk to be associated with
a symbol. For interworking thunks we only require one thunk, but range
extension thunks may require more than one.
Differential Revision: https://reviews.llvm.org/D34037
llvm-svn: 307136
On ARM the interworking thunks are only produced for branch instructions
that can't be changed into a blx instruction so only Thumb callers would
call Thumb thunks and only ARM callers would call ARM thunks. With range
extension thunks branch and link instructions may need a Thunk. These
instructions can be rewritten as a blx and can use either ARM or Thumb
thunks.
We introduce an isCompatibleWith() function so that a caller can check if
an existing Thunk is compatible before reusing it.
Differential Revision: https://reviews.llvm.org/D34035
llvm-svn: 307132
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
In preparation for supporting range extension thunks we now continually
call createThunks() until no more thunks are added. This requires us to
record the thunks we add on each pass and only merge the new ones into the
OutputSection. We also need to check if a Relocation is targeting a thunk
to prevent us from infinitely creating more thunks.
Differential Revision: https://reviews.llvm.org/D34034
llvm-svn: 305555
Thunks are now generated per InputSectionDescription instead of per
OutputSection. This allows created ThunkSections to be inserted directly
into InputSectionDescription.
Changes in this patch:
- Loop over InputSectionDescriptions to find relocations to Thunks
- Generate a ThunkSection per InputSectionDescription
- Remove synchronize() as we no longer need it
- Move fabricateDefaultCommands() before createThunks
Differential Revision: https://reviews.llvm.org/D33835
llvm-svn: 304887
In preparation for inserting Thunks into InputSectionDescription::Sections
extract the loop that finds InputSections that may have calls that need
Thunks. This isn't much benefit now but this will be useful when we have to
extract the InputSectionDescriptions::Sections from the script.
Differential Revision: https://reviews.llvm.org/D33834
llvm-svn: 304783
In preparation for inserting Thunks into InputSectionDescriptions this
simple change associates added Thunks with a vector of InputSections instead
of an OutputSection. As of now we are just using OutputSection::Sections.
Differential Revision: https://reviews.llvm.org/D33832
llvm-svn: 304782
This is PR33243. R_GOTONLY_PC_FROM_END was not in a list of link time constant
expressions and that was a result of confusiing messages like PR shows:
/usr/bin/ld.lld: error: /usr/lib/go/src/runtime/alg.go:47:
can't create dynamic relocation R_386_GOTPC against local symbol in readonly segment defined in /tmp/nice/go-link-597453838/go.o
Though in reality we just should not have try to create a dynamic relocation for this case at all.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D33717
llvm-svn: 304393
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
GetSection is a template because write calls relocate.
relocate has two parts. The non alloc code really has to be a
template, as it is looking a raw input file data.
The alloc part is only a template because of getSize.
This patch folds the value of getSize early, detemplates
getRelocTargetVA and splits relocate into a templated non alloc case
and a regular function for the alloc case. This has the nice advantage
of making sure we collect all the information we need for relocations
before getting to InputSection::relocateNonAlloc.
Since we know got is alloc, it can just call the function directly and
avoid the template.
llvm-svn: 303355
Nothing special here, just detemplates code that became possible
to detemplate after recent commits in a straghtforward way.
Differential revision: https://reviews.llvm.org/D33234
llvm-svn: 303237
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
It seems virtually everyone who tries to do LTO build with Clang and
LLD was hit by a mistake to forget using llvm-ar command to create
archive files. I wasn't an exception. Since this is an annoying common
issue, it is probably better to handle that gracefully rather than
reporting an error and tell the user to redo build with different
configuration.
Differential Revision: https://reviews.llvm.org/D32721
llvm-svn: 302083
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
Both functions always use the same GOT sections In<ELFT>::Got and
In<ELFT>::MipsGot respectively, so we do not need to pass them as an
argument.
llvm-svn: 299773
When the target of the TlsOffsetRel is non-preemptible we can write the
offset directly into the GOT without needing a dynamic relocation. This
is optional for dynamically linked executables but is required for static
linking.
This change adds the relocation to the GOT entry and a test case for
non-0 offsets so that if we miss out the offset the test won't spuriously
pass by virtue of the default value being 0.
Differential Revision: https://reviews.llvm.org/D31749
llvm-svn: 299751
The handleNoRelaxTlsRelocation handled both ARM and Mips as at a
high-level the actions of what to do when encountering a local dynamic or
global dynamic TLS relocation are the same. However due to Mips using a
custom GOT the differences of the implementation are enough that the
function became difficult to understand.
This change replaces handleNotRelaxTlsRelocation into
handleARMTlsRelocation() and handleMipsTlsRelocation() so that the ARM and
Mips specific code is isolated.
Differential Revision: https://reviews.llvm.org/D31748
llvm-svn: 299750
scanRelocs() does a lot of things. It fills InputSection's Relocations vector,
making a decision whether a TLS relocation should be relaxed or not,
and making a decision whether a GOT/PLT slot needs to be created or not.
They don't actually have to be done in a single loop. I want to separate
them so that some of them can be run concurently. As a first step, this
patch moves PLT/GOT slot assignment to beginning of the loop, so that
they just fall through to the next statements. This should make it clear
that that code doesn't affect other parts of the loop.
llvm-svn: 299615
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
For range extension thunks we will need to repeatedly call createThunks()
until no more thunks are created. We will need to retain the state of
Thunks that we have created so far to avoid recreating them on later
passes. This change does not change the functionality of createThunks().
Differential Revision: https://reviews.llvm.org/D31654
llvm-svn: 299530
Previous error message style:
error: /home/alice/src/bar.c:12: relocation R_X86_64_PLT32 cannot refer to absolute symbol 'answer' defined in /home/alice/src/foo.o
New error message style:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol: foo
>>> defined in /home/alice/src/foo.o
>>> referenced by bar.c:12 (/home/alice/src/bar.c:12)
>>> /home/alice/src/bar.o:(.text+0x1)
llvm-svn: 299390
Previously, undefined symbol errors are one line like this
and wasn't easy to read.
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:207: undefined symbol 'lld:🧝:EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true> >::addSection(lld:🧝:InputSectionBase*)'
This patch make it more structured like this.
bin/ld.lld: error: undefined symbol: lld:🧝:EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true>
>>> Referenced by Writer.cpp:207 (/ssd/llvm-project/lld/ELF/Writer.cpp:207)
>>> Writer.cpp.o in archive lib/liblldELF.a
Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html
Differential Revision: https://reviews.llvm.org/D31481
llvm-svn: 299097
This patch calls getAddend on a relocation only when the relocation is RELA.
That doesn't really improve runtime performance but should improve
readability as the code now matches the function description.
llvm-svn: 298828
Previously, computeAddend had many parameters but most of them were
used only for MIPS. The MIPS ABI is too odd that I don't want to mix
it into the regular code path. Splitting the function into non-MIPS
and MIPS parts makes the regular code path easy to follow.
llvm-svn: 298817
C is short for Chunk, but we are no longer using that term.
RI is probably short for relocation iterator, but this is not an interator.
llvm-svn: 298786
Previously, relocation offsets are recalculated for .eh_frame sections
inside the main loop, and that messed up the main loop. This patch
separates that logic into a dedicated class.
llvm-svn: 298785
The original code is a big `if` and `else` which ends with `continue`
like this:
if (cond) {
...
// fall through
} else {
...
continue;
}
This patch rewrites it with the following.
if (!cond) {
...
continue;
}
...
llvm-svn: 298672
I honestly do not understand this part of code as it is too tangled.
What I'm trying now is to carefully disentangle it by transforming
code without changing meaining to see if I can improve overall
readability.
llvm-svn: 298576
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
Summary:
When we perform LTO builds with a version of ar that does not
understand LLVM bitcode objects, we end up with undefined references,
because our archive files do not list the bitcode symbols in their
indices. The error messages do not make it clear what the real problem
is. This change adds a note that points out the likely problem and
solution. It is similar in spirit to r282633, but aims to avoid false
positives by only triggering when we see both undefined references and
archives without symbols in their indices.
Fixes PR32281.
Reviewers: davide, ruiu, tejohnson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31011
llvm-svn: 298124
Was fixed, details on review page.
Original commit message:
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 298062
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 297814
Being passed -z notext is a pretty strong indication that the user is
OK with text relocations. This is not the same behavior as bfd, but
bfd defaults to -z notext, so it has to try to avoid text relocations
and use them as a last resort.
llvm-svn: 297789
gold linker manual describes them as:
-z text Do not permit relocations in read-only segments
-z notext Permit relocations in read-only segments (default)
In LLD default is to not permit them. Patch implements -z notext.
Differential revision: https://reviews.llvm.org/D30530
llvm-svn: 297366
This change moves the calls to finalizeContent() for each synthetic section
before createThunks(). This will allow us to assign addresses prior to
calling createThunks(). As addition of thunks may add to the static
symbol table and may affect the size of the mips got section we introduce a
couple of additional member functions to update these values.
Differential revision: https://reviews.llvm.org/D29983
llvm-svn: 297277
This change fixes a bug in which the Mips LA25 Thunks are always assigned
to the same Output section as the caller and not the callee as expected.
Differential Revision: https://reviews.llvm.org/D30637
llvm-svn: 297135
In compare with D30458, this makes Bss/BssRelRo to be pure
synthetic sections.
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
SharedSymbols involved in creating copy relocations are
converted to DefinedRegular, what also simplifies things.
Differential revision: https://reviews.llvm.org/D30541
llvm-svn: 297008
In many places we reset Size to 0 before calling assignOffsets()
manually. Sometimes we don't do that.
It looks we can just always do that inside.
Previous code had:
template <class ELFT> void OutputSection::assignOffsets() {
uint64_t Off = Size;
And tests feels fine with Off = 0.
I think Off = Size make no sence.
Differential revision: https://reviews.llvm.org/D30463
llvm-svn: 296609
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
This patch removes NeedsCopyOrPltAddr and instead add two variables,
NeedsCopy and NeedsPltAddr. This uses one more bit in Symbol class,
but the actual size doesn't increase because we had unused bits.
This should improve code readability.
llvm-svn: 295287
This is slightly inefficient than the previous code, but that is really
negligible as this function is usually called at most only a few times.
llvm-svn: 295282
Previously, space in a BSS section for copy relocations are reserved
in a special way. We directly manipulated size of the BSS section.
r294577 changed the way of doing it. Now, we create an instance of
CopyRelSection (which is a synthetic input section) for each copy
relocation.
This patch removes the remains of the old way and add CopyRelSections
to BSS sections using `addSections` function, which is the usual
way to add an input section to an output section.
llvm-svn: 295278
In the target dependent code we already always return a int64_t. In
the target independent code we carefully use uintX_t, which has the
same result given 2 complement rules.
This just simplifies the code to use int64_t everywhere.
llvm-svn: 295263
When we need a copy relocation we create a synthetic SHT_NOBITS
section that contains the right amount of ZI and assign it to either
.bss or .rel.ro.bss as appropriate. This allows the dynamic relocation
to be placed on the InputSection, removing the last case where a
dynamic relocation is stored as an offset from the OutputSection. This
has the side effect that we can run assignOffsets() after scanRelocs()
without losing the additional ZI needed for the copy relocations.
Differential Revision: https://reviews.llvm.org/D29637
llvm-svn: 294577
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
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.
llvm-svn: 293290
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
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
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
llvm-svn: 291524
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.
llvm-svn: 290099
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
llvm-svn: 289045
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
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.
llvm-svn: 288803
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
llvm-svn: 288314
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
Rui Ueyama