Rather than report "undefined symbol: ", give more informative message
about the object file that defines the discarded section.
In particular, PR41133, if the section is a discarded COMDAT, print the
section group signature and the object file with the prevailing
definition. This is useful to track down some ODR issues.
We need to
* add `uint32_t DiscardedSecIdx` to Undefined for this feature.
* make ComdatGroups public and change its type to DenseMap<CachedHashStringRef, const InputFile *>
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D59649
llvm-svn: 361359
For a reference to a local symbol, ld.bfd and gold error if the symbol
is defined in a discarded section but accept it if the symbol is
undefined. This inconsistent behavior seems unnecessary for us (it
probably makes sense for them as they differentiate local/global
symbols, the error would mean more code).
Catch such errors. Symbol index 0 may be used by marker relocations,
e.g. R_*_NONE R_ARM_V4BX. Don't error on them.
The difference from D61563 (which caused msan failure) is we don't call
Sym.computeBinding() on local symbols - VersionId is uninitialized.
llvm-svn: 361213
This reverts commit r361144. It causes a use-of-uninitialized-value in
maybeReportUndefined at llvm/tools/lld/ELF/Relocations.cpp:682, as
detected by MemorySanitizer when local-undefined-symbol.s test is run.
llvm-svn: 361162
For a reference to a local symbol, ld.bfd and gold error if the symbol
is defined in a discarded section but accept it if the symbol is
undefined. This inconsistent behavior seems unnecessary for us (it
probably makes sense for them as they differentiate local/global
symbols, the error would mean more code).
Weaken the condition to getSymbol(Config->IsMips64EL) == 0 to catch such
errors. The symbol index can be 0 (e.g. R_*_NONE R_ARM_V4BX) and we shouldn't error on them.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D61563
llvm-svn: 361144
This is a mechanical rewrite of replaceSymbol(A, B) to A->replace(B).
I also added a comment to Symbol::replace().
Technically this change is not necessary, but this change makes code a
bit more concise.
Differential Revision: https://reviews.llvm.org/D62117
llvm-svn: 361123
This is the last patch of the series of patches to make it possible to
resolve symbols without asking SymbolTable to do so.
The main point of this patch is the introduction of
`elf::resolveSymbol(Symbol *Old, Symbol *New)`. That function resolves
or merges given symbols by examining symbol types and call
replaceSymbol (which memcpy's New to Old) if necessary.
With the new function, we have now separated symbol resolution from
symbol lookup. If you already have a Symbol pointer, you can directly
resolve the symbol without asking SymbolTable to do that.
Now that the nice abstraction become available, I can start working on
performance improvement of the linker. As a starter, I'm thinking of
making --{start,end}-lib faster.
--{start,end}-lib is currently unnecessarily slow because it looks up
the symbol table twice for each symbol.
- The first hash table lookup/insertion occurs when we instantiate a
LazyObject file to insert LazyObject symbols.
- The second hash table lookup/insertion occurs when we create an
ObjFile from LazyObject file. That overwrites LazyObject symbols
with Defined symbols.
I think it is not too hard to see how we can now eliminate the second
hash table lookup. We can keep LazyObject symbols in Step 1, and then
call elf::resolveSymbol() to do Step 2.
Differential Revision: https://reviews.llvm.org/D61898
llvm-svn: 360975
SymbolTable's add-family functions have lots of parameters because
when they have to create a new symbol, they forward given arguments
to Symbol's constructors. Therefore, the functions take at least as
many arguments as their corresponding constructors.
This patch simplifies the add-family functions. Now, the functions
take a symbol instead of arguments to construct a symbol. If there's
no existing symbol, a given symbol is memcpy'ed to the symbol table.
Otherwise, the functions attempt to merge the existing and a given
new symbol.
I also eliminated `CanOmitFromDynSym` parameter, so that the functions
take really one argument.
Symbol classes are trivially constructible, so looks like constructing
them to pass to add-family functions is as cheap as passing a lot of
arguments to the functions. A quick benchmark showed that this patch
seems performance-neutral.
This is a preparation for
http://lists.llvm.org/pipermail/llvm-dev/2019-April/131902.html
Differential Revision: https://reviews.llvm.org/D61855
llvm-svn: 360838
Patch by Mark Johnston!
Summary:
When the option is configured, ifunc calls do not go through the PLT;
rather, they appear as regular function calls with relocations
referencing the ifunc symbol, and the resolver is invoked when
applying the relocation. This is intended for use in freestanding
environments where text relocations are permissible and is incompatible
with the -z text option. The option is motivated by ifunc usage in the
FreeBSD kernel, where ifuncs are used to elide CPU feature flag bit
checks in hot paths. Instead of replacing the cost of a branch with that
of an indirect function call, the -z ifunc-noplt option is used to ensure
that ifunc calls carry no hidden overhead relative to normal function
calls.
Test Plan:
I added a couple of regression tests and tested the FreeBSD kernel
build using the latest lld sources.
To demonstrate the effects of the change, I used a micro-benchmark
which results in frequent invocations of a FreeBSD kernel ifunc. The
benchmark was run with and without IBRS enabled, and with and without
-zifunc-noplt configured. The observed speedup is small and consistent,
and is significantly larger with IBRS enabled:
https://people.freebsd.org/~markj/ifunc-noplt/noibrs.txthttps://people.freebsd.org/~markj/ifunc-noplt/ibrs.txt
Reviewed By: ruiu, MaskRay
Differential Revision: https://reviews.llvm.org/D61613
llvm-svn: 360685
This is based on D54720 by Sean Fertile.
When accessing a global symbol which is not defined in the translation unit,
compilers will generate instructions that load the address from the toc entry.
If the symbol is defined, non-preemptable, and addressable with a 32-bit
signed offset from the toc pointer, the address can be computed
directly. e.g.
addis 3, 2, .LC0@toc@ha # R_PPC64_TOC16_HA
ld 3, .LC0@toc@l(3) # R_PPC64_TOC16_LO_DS, load the address from a .toc entry
ld/lwa 3, 0(3) # load the value from the address
.section .toc,"aw",@progbits
.LC0: .tc var[TC],var
can be relaxed to
addis 3,2,var@toc@ha # this may be relaxed to a nop,
addi 3,3,var@toc@l # then this becomes addi 3,2,var@toc
ld/lwa 3, 0(3) # load the value from the address
We can delete the test ppc64-got-indirect.s as its purpose is covered by
newly added ppc64-toc-relax.s and ppc64-toc-relax-constants.s
Reviewed By: ruiu, sfertile
Differential Revision: https://reviews.llvm.org/D60958
llvm-svn: 360112
Make some small adjustment while touching the code: make parameters
const, use less_first(), etc.
Differential Revision: https://reviews.llvm.org/D60989
llvm-svn: 358943
Summary:
Fixes PR35242. A simplified reproduce:
thread_local int i; int f() { return i; }
% {g++,clang++} -fPIC -shared -ftls-model=local-dynamic -fuse-ld=lld a.cc
ld.lld: error: can't create dynamic relocation R_X86_64_DTPOFF32 against symbol: i in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
In isStaticLinkTimeConstant(), Syn.IsPreemptible is true, so it is not
seen as a constant. The error is then issued in processRelocAux().
A symbol of the local-dynamic TLS model cannot be preempted but it can
preempt symbols of the global-dynamic TLS model in other DSOs.
So it makes some sense that the variable is not static.
This patch fixes the linking error by changing getRelExpr() on
R_386_TLS_LDO_32 and R_X86_64_DTPOFF{32,64} from R_ABS to R_DTPREL.
R_PPC64_DTPREL_* and R_MIPS_TLS_DTPREL_* need similar fixes, but they are not handled in this patch.
As a bonus, we use `if (Expr == R_ABS && !Config->Shared)` to find
ld-to-le opportunities. R_ABS is overloaded here for such STT_TLS symbols.
A dedicated R_DTPREL is clearer.
Differential Revision: https://reviews.llvm.org/D60945
llvm-svn: 358870
This is https://bugs.llvm.org//show_bug.cgi?id=39857.
I added the comment with much more details to the bug page,
the short version is below.
The following script and code demonstrates the issue:
aliasto__text = __text;
SECTIONS {
.text 0x1000 : { __text = . ; *(.text) }
}
...
call aliasto__text
LLD fails with "cannot refer to absolute symbol: aliasto__text" error.
It happens because at the moment of scanning the relocations
we do not yet assign the correct/final/any section value for the symbol aliasto__text.
I made a change to Relocations.cpp to fix that.
Also, I had to remove the symbol-location.s test case completely, because now it does not
trigger any error. Since now all linker scripts symbols are resolved to constants, no
errors can be triggered at all it seems. I checked that it is consistent with the behavior
of bfd and gold (they do not trigger errors for the case from symbol-location.s), so it should
be OK. I.e. at least it is probably not the best possible, but natural behavior we obtained.
Differential revision: https://reviews.llvm.org/D55423
llvm-svn: 358652
Summary:
This should address remaining issues discussed in PR36555.
Currently R_GOT*_FROM_END are exclusively used by x86 and x86_64 to
express relocations types relative to the GOT base. We have
_GLOBAL_OFFSET_TABLE_ (GOT base) = start(.got.plt) but end(.got) !=
start(.got.plt)
This can have problems when _GLOBAL_OFFSET_TABLE_ is used as a symbol, e.g.
glibc dl_machine_dynamic assumes _GLOBAL_OFFSET_TABLE_ is start(.got.plt),
which is not true.
extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden;
return _GLOBAL_OFFSET_TABLE_[0]; // R_X86_64_GOTPC32
In this patch, we
* Change all GOT*_FROM_END to GOTPLT* to fix the problem.
* Add HasGotPltOffRel to denote whether .got.plt should be kept even if
the section is empty.
* Simplify GotSection::empty and GotPltSection::empty by setting
HasGotOffRel and HasGotPltOffRel according to GlobalOffsetTable early.
The change of R_386_GOTPC makes X86::writePltHeader simpler as we don't
have to compute the offset start(.got.plt) - Ebx (it is constant 0).
We still diverge from ld.bfd (at least in most cases) and gold in that
.got.plt and .got are not adjacent, but the advantage doing that is
unclear.
Reviewers: ruiu, sivachandra, espindola
Subscribers: emaste, mehdi_amini, arichardson, dexonsmith, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59594
llvm-svn: 356968
Non-GOT non-PLT relocations to non-preemptible ifuncs result in the
creation of a canonical PLT, which now takes the identity of the IFUNC
in the symbol table. This (a) ensures address consistency inside and
outside the module, and (b) fixes a bug where some of these relocations
end up pointing to the resolver.
Fixes (at least) PR40474 and PR40501.
Differential Revision: https://reviews.llvm.org/D57371
llvm-svn: 353981
A follow up to the intial patch that unblocked linking against libgcc.
For lld we don't need to bother tracking which objects have got based small
code model relocations. This is due to the fact that the compilers on
powerpc64 use the .toc section to generate indirections to symbols (rather then
using got relocations) which keeps the got small. This makes overflowing a
small code model got relocation very unlikely.
Differential Revision: https://reviews.llvm.org/D57245
llvm-svn: 353849
Summary:
R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error.
R_PPC64_GOT_TLSGD16_HA
R_PPC64_GOT_TLSGD16_LO
R_PPC64_TLSGD R_TLSDESC_CALL
R_PPC64_REL24 __tls_get_addr
Reviewers: ruiu, sfertile, syzaara, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57673
llvm-svn: 353262
Guessing that the slashes used in the scripts SECTION command was causing the
windows related failures in the added test.
Original commit message:
Small code model global variable access on PPC64 has a very limited range of
addressing. The instructions the relocations are used on add an offset in the
range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving
an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled
with medium and large code models when the binary grows too large for small code
model, there are small code model relocations in the crt files and libgcc.a
which are typically shipped with the distros, and the ABI dictates that linkers
must allow linking of relocatable object files using different code models.
To minimze the chance of relocation overflow, any file that contains a small
code model relocation should have its .toc section placed closer to the .got
then any .toc from a file without small code model relocations.
Differential Revision: https://reviews.llvm.org/D56920
llvm-svn: 352071
Small code model global variable access on PPC64 has a very limited range of
addressing. The instructions the relocations are used on add an offset in the
range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving
an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled
with medium and large code models when the binary grows too large for small code
model, there are small code model relocations in the crt files and libgcc.a
which are typically shipped with the distros, and the ABI dictates that linkers
must allow linking of relocatable object files using different code models.
To minimze the chance of relocation overflow, any file that contains a small
code model relocation should have its .toc section placed closer to the .got
then any .toc from a file without small code model relocations.
Differential Revision: https://reviews.llvm.org/D56920
llvm-svn: 351978
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
As a follow on to D56666 (r351186) there is a case when taking the address
of an ifunc when linking -pie that can generate a spurious can't create
dynamic relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol in readonly
segment. Specifically the case is where the ifunc is in the same
translation unit as the address taker, so given -fpie the compiler knows
the ifunc is defined in the executable so it can use a non-got-generating
relocation.
The error message is due to R_AARCH64_PLT_PAGE_PC not being added to
isRelExpr, its non PLT equivalent R_AARCH64_PAGE_PC is already in
isRelExpr.
Differential Revision: https://reviews.llvm.org/D56724
llvm-svn: 351335
r347650 fixed pr38074 for AArch64 for static linking. It added two new
RelExpr instances R_AARCH64_GOT_PAGE_PC_PLT and R_GOT_PLT. These need to be
added to isStaticLinkTimeConstant so that the address of an ifunc can be
taken when building a shared library.
fixes pr40250
Differential Revision: https://reviews.llvm.org/D56666
llvm-svn: 351186
Summary:
This is a common error, and because many people don't know what the key
function is, it is sometimes very confusing.
The doc was originally written by Brooks Moses and slightly edited by me.
Reviewers: MaskRay, espindola
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55968
llvm-svn: 349941
When we report an error for symbols defined in the linker script,
we do not report the location properly.
For example:
ld.lld: error: relocation R_AARCH64_CALL26 cannot refer to absolute symbol: aliasto__text
>>> defined in <internal>
>>> referenced by rtoabs.o:(.text+0x4)
This patch fixes that.
Differential revision: https://reviews.llvm.org/D55360
llvm-svn: 349612
This patch also makes getPltEntryOffset a non-member function because
it doesn't depend on any private members of the TargetInfo class.
I tried a few different ideas, and it seems this change fits in best to me.
Differential Revision: https://reviews.llvm.org/D54981
llvm-svn: 347781
This is https://bugs.llvm.org/show_bug.cgi?id=38074.
The issue is that when calling a function, LLD generates a
.got entry that points to the IFUNC resolver function when
instead, it should use the PLT entries properly for
handling the IFUNC.
So we should create a got entry that points to PLT entry,
which itself loads the value from
.got.plt, relocated with R_*_IRELATIVE to make things work.
Patch do that.
Differential revision: https://reviews.llvm.org/D54314
llvm-svn: 347650
On PowerPC64, when a function call offset is too large to encode in a call
instruction the address is stored in a table in the data segment. A thunk is
used to load the branch target address from the table relative to the
TOC-pointer and indirectly branch to the callee. When linking position-dependent
code the addresses are stored directly in the table, for position-independent
code the table is allocated and filled in at load time by the dynamic linker.
For position-independent code the branch targets could have gone in the .got.plt
but using the .branch_lt section for both position dependent and position
independent binaries keeps it consitent and helps keep this PPC64 specific logic
seperated from the target-independent code handling the .got.plt.
Differential Revision: https://reviews.llvm.org/D53408
llvm-svn: 346877
Previously, we uncompress all compressed sections before doing anything.
That works, and that is conceptually simple, but that could results in
a waste of CPU time and memory if uncompressed sections are then
discarded or just copied to the output buffer.
In particular, if .debug_gnu_pub{names,types} are compressed and if no
-gdb-index option is given, we wasted CPU and memory because we
uncompress them into newly allocated bufers and then memcpy the buffers
to the output buffer. That temporary buffer was redundant.
This patch changes how to uncompress sections. Now, compressed sections
are uncompressed lazily. To do that, `Data` member of `InputSectionBase`
is now hidden from outside, and `data()` accessor automatically expands
an compressed buffer if necessary.
If no one calls `data()`, then `writeTo()` directly uncompresses
compressed data into the output buffer. That eliminates the redundant
memory allocation and redundant memcpy.
This patch significantly reduces memory consumption (20 GiB max RSS to
15 Gib) for an executable whose .debug_gnu_pub{names,types} are in total
5 GiB in an uncompressed form.
Differential Revision: https://reviews.llvm.org/D52917
llvm-svn: 343979
The GOT is referenced through the symbol _GLOBAL_OFFSET_TABLE_ .
The relocation added calculates the offset into the global offset table for
the entry of a symbol. In order to get the correct TargetVA I needed to
create an new relocation expression, HEXAGON_GOT. It does
Sym.getGotVA() - In.GotPlt->getVA().
Differential Revision: https://reviews.llvm.org/D52744
llvm-svn: 343784
This patch splits ThunkCreator::mergeThunks into two smaller functions.
Also adds blank lines to various places so that the code doesn't look
too dense.
llvm-svn: 343732
Summary:
This patch adds a new flag, --warn-ifunc-textrel, to work around a glibc bug. When a code with ifunc symbols is used to produce an object file with text relocations, lld always succeeds. However, if that object file is linked using an old version of glibc, the resultant binary just crashes with segmentation fault when it is run (The bug is going to be corrected as of glibc 2.19).
Since there is no way to tell beforehand what library the object file will be linked against in the future, there does not seem to be a fool-proof way for lld to give an error only in cases where the binary will crash. So, with this change (dated 2018-09-25), lld starts to give a warning, contingent on a new command line flag that does not have a gnu counter part. The default value for --warn-ifunc-textrel is false, so lld behaviour will not change unless the user explicitly asks lld to give a warning. Users that link with a glibc library with version 2.19 or newer, or does not use ifunc symbols, or does not generate object files with text relocations do not need to take any action. Other users may consider to start passing warn-ifunc-textrel to lld to get early warnings.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: grimar, MaskRay, markj, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52430
llvm-svn: 343628
Previously, if you invoke lld's `main` more than once in the same process,
the second invocation could fail or produce a wrong result due to a stale
pointer values of the previous run.
Differential Revision: https://reviews.llvm.org/D52506
llvm-svn: 343009
This patch adds the target call back relaxTlsIeToLe to support TLS relaxation
from initial exec to local exec model.
Differential Revision: https://reviews.llvm.org/D48091
llvm-svn: 340281
Older Arm architectures do not support the MOVT and MOVW instructions so we
must use an alternative sequence of instructions to transfer control to the
destination.
Assuming at least Armv5 this patch adds support for Thunks that load or add
to the program counter. Note that there are no Armv5 Thumb Thunks as there
is no Thumb branch instruction in Armv5 that supports Thunks. These thunks
will not work for Armv4t (arm7tdmi) as this architecture cannot change state
from using the LDR or ADD instruction.
Differential Revision: https://reviews.llvm.org/D50077
llvm-svn: 340160
We have a dead piece of code there which is impossible to trigger
using regular objects I believe.
Patch removes it and adds a test case showing how this condition
can be triggered with use of a broken object and crash the linker.
llvm-svn: 339680
The code involved was simply dead. `IgnoreAll` value is used in
`maybeReportUndefined` only which is never called for -r.
And at the same time `IgnoreAll` was set only for -r.
llvm-svn: 339672
That piece of code is really very old and "protected"
from TLS relocations against symbol in non-allocatable sections.
It is useless because normally non-alloc sections have relocations
with allocatable targets, but not the reverse.
And so the code was simply dead.
llvm-svn: 339553
Patch by PkmX.
This patch makes lld recognize RISC-V target and implements basic
relocation for RV32/RV64 (and RVC). This should be necessary for static
linking ELF applications.
The ABI documentation for RISC-V can be found at:
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md.
Note that the documentation is far from complete so we had to figure out
some details from bfd.
The patch should be pretty straightforward. Some highlights:
- A new relocation Expr R_RISCV_PC_INDIRECT is added. This is needed as
the low part of a PC-relative relocation is linked to the corresponding
high part (auipc), see:
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#pc-relative-symbol-addresses
- LLVM's MC support for RISC-V is very incomplete (we are working on
this), so tests are given in objectyaml format with the original
assembly included in the comments. Once we have complete support for
RISC-V in MC, we can switch to llvm-as/llvm-objdump.
- We don't support linker relaxation for now as it requires greater
changes to lld that is beyond the scope of this patch. Once this is
accepted we can start to work on adding relaxation to lld.
Differential Revision: https://reviews.llvm.org/D39322
llvm-svn: 339364
During copy relocation of a variable defined in a DSO, if a TLS variable in that DSO happens to have the same st_value, it would also be copied. This was unnecessary because the addresses of TLS variables are relative to TLS segment. They don't interfere with non-TLS variables.
This copying behavior can be harmful in the following scenario:
For function-scope thread-local variables with non-trivial constructors,
they have guard variables. In the case of x86_64 general-dynamic model:
template <int N>
void foo() {
thread_local std::string a;
}
GOT[n] R_X86_64_DTPMOD64 guard variable for a
GOT[n+1] R_X86_64_DTPOFF64 guard variable for a
GOT[n+2] R_X86_64_DTPMOD64 a
GOT[n+3] R_X86_64_DTPOFF64 a
a and its guard variable are both represented as TLS variables, which
should be within the same module. If one is copy relocated to the main
module while the other is not, their module ID will mismatch and can
cause access without prior construction.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D50289
llvm-svn: 339042
Patch by Matthew Koontz!
Before, direct calls to __wrap_sym would not map to valid PLT entries,
so they would crash at runtime. This change maps such calls to the same
PLT entry as calls to sym that are then wrapped.
Differential Revision: https://reviews.llvm.org/D48502
llvm-svn: 336609
Patch by Rahul Chaudhry!
This change adds experimental support for SHT_RELR sections, proposed
here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg
Pass '--pack-dyn-relocs=relr' to enable generation of SHT_RELR section
and DT_RELR, DT_RELRSZ, and DT_RELRENT dynamic tags.
Definitions for the new ELF section type and dynamic array tags, as well
as the encoding used in the new section are all under discussion and are
subject to change. Use with caution!
Pass '--use-android-relr-tags' with '--pack-dyn-relocs=relr' to use
SHT_ANDROID_RELR section type instead of SHT_RELR, as well as
DT_ANDROID_RELR* dynamic tags instead of DT_RELR*. The generated
section contents are identical.
'--pack-dyn-relocs=android+relr --use-android-relr-tags' enables both
'--pack-dyn-relocs=android' and '--pack-dyn-relocs=relr': lld will
encode the relative relocations in a SHT_ANDROID_RELR section, and pack
the rest of the dynamic relocations in a SHT_ANDROID_REL(A) section.
Differential Revision: https://reviews.llvm.org/D48247
llvm-svn: 336594
This patch adds the target call back relaxTlsLdToLe to support TLS relaxation
from local dynamic to local exec model.
Differential Revision: https://reviews.llvm.org/D48293
llvm-svn: 336559
The local dynamic TLS access on PPC64 ELF v2 ABI uses R_PPC64_GOT_DTPREL16*
relocations when a TLS variables falls outside 2 GB of the thread storage
block. This patch adds support for these relocations by adding a new RelExpr
called R_TLSLD_GOT_OFF which emits a got entry for the TLS variable relative
to the dynamic thread pointer using the relocation R_PPC64_DTPREL64. It then
evaluates the R_PPC64_GOT_DTPREL16* relocations as the got offset for the
R_PPC64_DTPREL64 got entries.
Differential Revision: https://reviews.llvm.org/D48484
llvm-svn: 335732
In glibc libc.so.6, the multiple versions of sys_errlist share the same Symbol instance. When sys_errlist is copy relocated, we would replace SharedSymbol with Defined in the first iteration of the following loop:
for (SharedSymbol *Sym : getSymbolsAt<ELFT>(SS))
Then in the second iteration, we think the symbol (which has been changed to Defined) is still SharedSymbol and screw up (the address ends up in the `Size` field).
llvm-svn: 334432
Almost all entries inside MIPS GOT are referenced by signed 16-bit
index. Zero entry lies approximately in the middle of the GOT. So the
total number of GOT entries cannot exceed ~16384 for 32-bit architecture
and ~8192 for 64-bit architecture. This limitation makes impossible to
link rather large application like for example LLVM+Clang. There are two
workaround for this problem. The first one is using the -mxgot
compiler's flag. It enables using a 32-bit index to access GOT entries.
But each access requires two assembly instructions two load GOT entry
index to a register. Another workaround is multi-GOT. This patch
implements it.
Here is a brief description of multi-GOT for detailed one see the
following link https://dmz-portal.mips.com/wiki/MIPS_Multi_GOT.
If the sum of local, global and tls entries is less than 64K only single
got is enough. Otherwise, multi-got is created. Series of primary and
multiple secondary GOTs have the following layout:
```
- Primary GOT
Header
Local entries
Global entries
Relocation only entries
TLS entries
- Secondary GOT
Local entries
Global entries
TLS entries
...
```
All GOT entries required by relocations from a single input file
entirely belong to either primary or one of secondary GOTs. To reference
GOT entries each GOT has its own _gp value points to the "middle" of the
GOT. In the code this value loaded to the register which is used for GOT
access.
MIPS 32 function's prologue:
```
lui v0,0x0
0: R_MIPS_HI16 _gp_disp
addiu v0,v0,0
4: R_MIPS_LO16 _gp_disp
```
MIPS 64 function's prologue:
```
lui at,0x0
14: R_MIPS_GPREL16 main
```
Dynamic linker does not know anything about secondary GOTs and cannot
use a regular MIPS mechanism for GOT entries initialization. So we have
to use an approach accepted by other architectures and create dynamic
relocations R_MIPS_REL32 to initialize global entries (and local in case
of PIC code) in secondary GOTs. But ironically MIPS dynamic linker
requires GOT entries and correspondingly ordered dynamic symbol table
entries to deal with dynamic relocations. To handle this problem
relocation-only section in the primary GOT contains entries for all
symbols referenced in global parts of secondary GOTs. Although the sum
of local and normal global entries of the primary got should be less
than 64K, the size of the primary got (including relocation-only entries
can be greater than 64K, because parts of the primary got that overflow
the 64K limit are used only by the dynamic linker at dynamic link-time
and not by 16-bit gp-relative addressing at run-time.
The patch affects common LLD code in the following places:
- Added new hidden -mips-got-size flag. This flag required to set low
maximum size of a single GOT to be able to test the implementation using
small test cases.
- Added InputFile argument to the getRelocTargetVA function. The same
symbol referenced by GOT relocation from different input file might be
allocated in different GOT. So result of relocation depends on the file.
- Added new ctor to the DynamicReloc class. This constructor records
settings of dynamic relocation which used to adjust address of 64kb page
lies inside a specific output section.
With the patch LLD is able to link all LLVM+Clang+LLD applications and
libraries for MIPS 32/64 targets.
Differential revision: https://reviews.llvm.org/D31528
llvm-svn: 334390
The original computation for shared object symbol alignment is wrong when
st_value equals 0. It is very unusual for dso symbols to have st_value equal 0.
But when it happens, it causes obscure run time bugs.
Differential Revision: https://reviews.llvm.org/D47602
llvm-svn: 334135
Add support for the R_PPC64_GOT_TLSLD16 relocations used to build the address of
the tls_index struct used in local-dynamic tls.
Differential Revision: https://reviews.llvm.org/D47538
llvm-svn: 333681
getRelocTargetVA for R_TLSGD and R_TLSLD RelExprs calculate an offset from the
end of the got, so adjust the names to reflect this.
Differential Revision: https://reviews.llvm.org/D47379
llvm-svn: 333674
Adds handling of all the relocation types for general-dynamic thread local
storage.
Differential Revision: https://reviews.llvm.org/D47325
llvm-svn: 333420
Both R_PPC_CALL and R_PPC_CALL_PLT Exprs map to the R_PPC64_REL24 relocation
which has the form Sym + addend - P.
Differential Revision: https://reviews.llvm.org/D46654
llvm-svn: 332127
The current support for V1 ABI in LLD is incomplete.
This patch removes V1 ABI support and changes the default behavior to V2 ABI,
issuing an error when using the V1 ABI. It also updates the testcases to V2
and removes any V1 specific tests.
Differential Revision: https://reviews.llvm.org/D46316
llvm-svn: 331529
This is slightly simpler to read IMHO. Now if a symbol has a position
in the file, it is Defined.
The main motivation is that with this a SharedSymbol doesn't need a
section, which reduces the size of SymbolUnion.
With this the peak allocation when linking chromium goes from 568.1 to
564.2 MB.
llvm-svn: 330966
It returns a different Expr only in the case of creating a function
symbol pointing to its plt entry. We can just add a call to
addPltEntry to avoid that and return void.
With this patch further simplifications of how we handle copy
relocations are possible.
llvm-svn: 330960
As was mentioned in comments for D45158,
isPicRel's name does not make much sense,
because what this method does is checks if
we need to create the dynamic relocation or not.
Instead of renaming it to something different,
we can 'isPicRel' completely.
We can reuse the getDynRel method.
They are logically very close, getDynRel can just return
R_*_NONE in case no dynamic relocation should be produced
and that would simplify things and avoid functionality
correlation/duplication with 'isPicRel'.
The patch does this change.
Differential revision: https://reviews.llvm.org/D45248
llvm-svn: 329275
Now that we have the ability to create short thunks, it is beneficial
for thunk sections to be surrounded by ThunkSectionSpacing bytes
of code on both sides in order to increase the likelihood that the
distance from the thunk to the target will be sufficiently small to
allow for the creation of a short thunk. This is currently the case
for most thunks that we create, except for the last one, which could,
depending on the size of the output section, potentially appear near
the end and therefore have a relatively small amount of code after it.
This patch moves the last thunk section to ThunkSectionSpacing bytes
before the end of the output section, as long as the section is larger
than 2*ThunkSectionSpacing bytes. It reduces the size of Chromium
for Android's .text section by 32KB.
Differential Revision: https://reviews.llvm.org/D44966
llvm-svn: 328889
This "fixes" PR36678 by just producing an error when we find a case
where we would produce an plt entry that used ebx but ebx would not be
set.
llvm-svn: 327542
This avoids creating multiple thunks for symbols with aliases or which
belong to ICF'd sections. This patch reduces the size of Chromium for
Android by 260KB (0.8% of .text).
Differential Revision: https://reviews.llvm.org/D44284
llvm-svn: 327154
This should resolve the issue that lld build fails in some hosts
that uses case-insensitive file system.
Differential Revision: https://reviews.llvm.org/D43788
llvm-svn: 326339
The profailing style in lld seem to be to not include such empty lines.
Clang-tidy/clang-format seem to handle this just fine.
Differential Revision: https://reviews.llvm.org/D43528
llvm-svn: 325629
Now that we have R_ADDEND, UseSymVA was redundant. We only want to
write the symbol virtual address when using an expression other than
R_ADDEND.
llvm-svn: 325360
Summary:
This follows up on r321889 where writing of Elf_Rel addends was partially
moved to RelocationBaseSection. This patch ensures that the addends are
always written to the output section when a input section uses RELA but the
output is REL.
Differential Revision: https://reviews.llvm.org/D42843
llvm-svn: 325328
Summary:
While trying to make a linker script behave the same way with lld as it did
with bfd, I discovered that lld currently doesn't diagnose overlapping
output sections. I was getting very strange runtime failures which I
tracked down to overlapping sections in the resulting binary. When linking
with ld.bfd overlapping output sections are an error unless
--noinhibit-exec is passed and I believe lld should behave the same way
here to avoid surprising crashes at runtime.
The patch also uncovered an errors in the tests: arm-thumb-interwork-thunk
was creating a binary where .got.plt was placed at an address overlapping
with .got.
Reviewers: ruiu, grimar, rafael
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D41046
llvm-svn: 323856
Symbol had both Visibility and getVisibility() and they had different
meanings. That is just too easy to get wrong.
getVisibility() would compute the visibility of a particular symbol
(foo in bar.o), and Visibility stores the computed value we will put
in the output.
There is only one case when we want what getVisibility() provides, so
inline it.
llvm-svn: 322590
When we have --icf=safe we should be able to define --icf=all as a
shorthand for --icf=safe --ignore-function-address-equality.
For now --ignore-function-address-equality is used only to control
access to non preemptable symbols in shared libraries.
llvm-svn: 322152
This splits relocation processing in two steps.
First, analyze what needs to be done at the relocation spot. This can
be a constant (non preemptible symbol, relative got reference, etc) or
require a dynamic relocation. At this step we also consider creating
copy relocations.
Once that is done we decide if we need a got or a plt entry.
The code is simpler IMHO. For example:
- There is a single call to isPicRel since the logic is not split
among adjustExpr and the caller.
- R_MIPS_GOTREL is simple to handle now.
- The tracking of what is preemptible or not is much simpler now.
This also fixes a regression with symbols being both in a got and copy
relocated. They had regressed in r268668 and r268149.
The other test changes are because of error messages changes or the
order of two relocations in the output.
llvm-svn: 322047
The body of the in scanRelocs is fairly big. This moves it to its own
function.
It is not a big readability win by itself, but should help further
refactoring.
llvm-svn: 322035
This makes adjustExpr a bit simpler too IMHO.
It seems that some of the complication around relocation processing
is that we are trying to create copy relocations too early. It seems
we could handle a few simple cases first and continue.
llvm-svn: 321507
Previously we failed to resolve them when produced executables:
"relocation R_X86_64_32 cannot be used against shared object; recompile with -fPIC"
Patch fixes it so that we resolve them to 0 for executables.
And for -shared case we still should produce the relocation.
This finishes fixing PR35720.
DIfferential revision: https://reviews.llvm.org/D41551
llvm-svn: 321473
If a relocation cannot be implemented by the dynamic linker and the
section is rw, allow creating a plt entry to use as the function
address as if the section was ro.
This matches bfd and gold. It also matches our behavior with -z
notext.
llvm-svn: 321430
We normally avoid "switch (Config->EKind)", but in this case I think
it is worth it.
It is only executed when there is an error and it allows detemplating
a lot of code.
llvm-svn: 321404
This is part of PR35720.
Currently LLD allows dynamic relocations against text when -z notext is given.
Though for non-PIC relocations like R_X86_64_PC32 that does not work,
we produce "relocation R_X86_64_PC32 cannot be used against shared object;"
error because they may overflow in runtime.
Solution implemented is to use PLT for them.
Differential revision: https://reviews.llvm.org/D41541
llvm-svn: 321400
This reduces total allocations when linking clang fsds from 263.21MB
to 174.62MB.
This also has some very nice speed improvements on some
benchmarks. Chromium and clang fsds link 6% faster.
llvm-svn: 319976
This includes a fix to mark copy reloc aliases as used.
Original message:
[ELF] Do not keep symbols if they referenced only from discarded sections.
This patch also ensures that in case of "--as-needed" is used,
DT_NEEDED entries are not created if they are required only by
these eliminated symbols.
llvm-svn: 319215
Summary:
The bug triggers when the following conditions are met:
- A thunk is created in a given input section S
- A linker script is specified
- There is at least one matcher in the linker script .text section output
that does not match any of the sections in the input files, before the matcher
that matches section S.
The issue was found when linking the FreeBSD kernel for MIPS when built
with -fPIC. Patch by Alfredo Mazzinghi.
Reviewers: ruiu, psmith, atanasyan
Reviewed By: ruiu
Subscribers: peter.smith, emaste, sdardis, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D40174
llvm-svn: 318653
The ISR in the comment should read ISD for InputSectionDescription. The use
of ISR (InputSectionRange) was from the original implementation that did not
use the sections from InputSectionDescription directly.
llvm-svn: 317469
Now that DefinedRegular is the only remaining derived class of
Defined, we can merge the two classes.
Differential Revision: https://reviews.llvm.org/D39667
llvm-svn: 317448
Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by
perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)
nd clang-format-diff.
Differential Revision: https://reviews.llvm.org/D39459
llvm-svn: 317370
This is PR34826.
Currently LLD is unable to report line number when reporting
duplicate declaration of some variable.
That happens because for extracting line information we always use
.debug_line section content which describes mapping from machine
instructions to source file locations, what does not help for
variables as does not describe them.
In this patch I am taking the approproate information about
variables locations from the .debug_info section.
Differential revision: https://reviews.llvm.org/D38721
llvm-svn: 317080
SymbolBody and Symbol were separated classes due to a historical reason.
Symbol used to be a pointer to a SymbolBody, and the relationship
between Symbol and SymbolBody was n:1.
r2681780 changed that. Since that patch, SymbolBody and Symbol are
allocated next to each other to improve memory locality, and they have
1:1 relationship now. So, the separation of Symbol and SymbolBody no
longer makes sense.
This patch merges them into one class. In order to avoid updating too
many places, I chose SymbolBody as a unified name. I'll rename it Symbol
in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D39406
llvm-svn: 317006
This change allows Thunks to be added on multiple passes. To do this we must
merge only the thunks added in each pass, and deal with thunks that have
drifted out of range of their callers.
A thunk may end out of range of its caller if enough thunks are added in
between the caller and the thunk. To handle this we create another thunk.
Differential Revision: https://reviews.llvm.org/D34692
llvm-svn: 316754
This change adds initial support for range extension thunks. All thunks must
be created within the first pass so some corner cases are not supported. A
follow up patch will add support for multiple passes.
With this change the existing tests arm-branch-error.s and
arm-thumb-branch-error.s now no longer fail with an out of range branch.
These have been renamed and tests added for the range extension thunk.
Differential Revision: https://reviews.llvm.org/D34691
llvm-svn: 316752
When an OutputSection is larger than the branch range for a Target we
need to place thunks such that they are always in range of their caller,
and sufficiently spaced to maximise the number of callers that can use
the thunk. We use the simple heuristic of placing the
ThunkSection at intervals corresponding to a target specific branch range.
If the OutputSection is small we put the thunks at the end of the executable
sections.
Differential Revision: https://reviews.llvm.org/D34689
llvm-svn: 316751
Instead of maintaining a map of the std::vector to ThunkSections, record the
ThunkSections directly in InputSectionDescription.
Differential Revision: https://reviews.llvm.org/D37743
llvm-svn: 316750
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D39259
llvm-svn: 316624
Relocations.cpp is still head-scratching. Even though relocations are
processed by multiple functions, the functions are effectively one
gigantic function with lots of local and global shared states, because
they are really tightly coupled. It is really hard to predict whether
a change to a function will or will not affect other functions behaviors.
What I'm trying to do is to rewrite the code without breaking the
existing tests so that the code can tolerate a more aggressive
refactoring (i.e. splitting it to logically separated steps).
llvm-svn: 315673
This is not a mechanical transformation. Even though I believe this
patch is correct, I'm not 100% sure if lld with this patch behaves
exactly the same way as before on all edge cases. At least all tests
still pass.
I'm submitting this patch because it took almost a day to understand
this function, and I don't want to lose it.
llvm-svn: 315658
This patch merges computeAddend and computeMipsAddend.
Getting an addend for a relocation is usually pretty easy:
it is either in the r_addend field (if RELA) or in a target
section (if REL).
However, MIPS has many special rules that are different from
other ELF ABIs. I don't think there were technical reasons to
be different, but the reality is that they are different.
It is unfortunate that we had to pass many parameters to
computeAddend, but it seems unavoidable because of MIPS.
llvm-svn: 315617
This is an attempt to make lld's relocation handler code understandable.
Since I don't fully understand what exactly this function does for all
possible cases (I believe no one can), I'm not really sure if this patch
is NFC, but at least no functionality change intended. All tests still pass.
llvm-svn: 315612
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
Fangrui Song