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
gold accepts quoted strings. binutils requires quoted strings for some
kinds of symbols, e.g.:
it accepts quoted symbols with @ in name:
$ echo 'EXTERN("__libc_start_main@@GLIBC_2.2.5")' > a.script
$ g++ a.script
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
but rejects them if unquoted:
$ echo 'EXTERN(__libc_start_main@@GLIBC_2.2.5)' > a.script
$ g++ a.script
a.script: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
To maintain compatibility with existing linker scripts support quoted
strings in lld as well.
Patch by Lucian Adrian Grijincu.
Differential Revision: https://reviews.llvm.org/D57987
llvm-svn: 353756
R_X86_64_PC{8,16} relocations are sign-extended, so when we check
for relocation overflow, we had to use checkInt instead of checkUInt.
I confirmed that GNU linkers create the same output for the test case.
llvm-svn: 353437
This is the same as D57749, but for x64 target.
"ELF Handling For Thread-Local Storage" p41 says (https://www.akkadia.org/drepper/tls.pdf):
R_X86_64_GOTTPOFF relocation is used for IE TLS models.
Hence if linker sees this relocation we should add DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57821
llvm-svn: 353378
With the following changes:
1) Compilation fix:
std::atomic<bool> HasStaticTlsModel = false; ->
std::atomic<bool> HasStaticTlsModel{false};
2) Adjusted the comment in code.
Initial commit message:
DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.
Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57749
----
Modified : /lld/trunk/ELF/Arch/X86.cpp
Modified : /lld/trunk/ELF/Config.h
Modified : /lld/trunk/ELF/SyntheticSections.cpp
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model1.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model2.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model3.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model4.s
Added : /lld/trunk/test/ELF/i386-static-tls-model.s
Modified : /lld/trunk/test/ELF/i386-tls-ie-shared.s
Modified : /lld/trunk/test/ELF/tls-dynamic-i686.s
Modified : /lld/trunk/test/ELF/tls-opt-iele-i686-nopic.s
llvm-svn: 353299
DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.
Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57749
llvm-svn: 353293
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
Summary:
This follows the ld.bfd/gold behavior.
The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors:
// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }
// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }
// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: llvm-commits, emaste, arichardson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57569
llvm-svn: 352943
Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking
an executable. This patch implements a check to error on undefined
symbols in a shared object, if all of its DT_NEEDED entries are seen.
Our approach resembles the one used in gold, achieves a good balance to
be useful but not too smart (ld.bfd traces all DSOs and emulates the
behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from undefined
reference errors issued for relocations. It is most effective when there
are DSOs that were not linked with -z defs (e.g. when static sanitizers
runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
llvm-svn: 352826
Previously we were never setting this which means it was always being
set to Default (-O2/-Os).
Differential Revision: https://reviews.llvm.org/D57422
llvm-svn: 352667
Summary:
After rLLD344952 ("Add OUTPUT_FORMAT linker script directive support"),
using BFD names such as `elf64-x86-64-freebsd` the `OUTPUT_FORMAT`
linker script command does not work anymore, resulting in errors like:
```
ld: error: /home/dim/src/clang800-import/stand/efi/loader/arch/amd64/ldscript.amd64:2: unknown output format name: elf64-x86-64-freebsd
>>> OUTPUT_FORMAT("elf64-x86-64-freebsd", "elf64-x86-64-freebsd", "elf64-x86-64-freebsd")
>>> ^
```
To fix this, recognize a `-freebsd` suffix in BFD names, and also set
`Configuration::OSABI` to `ELFOSABI_FREEBSD` for those cases.
Add and/or update several test cases to check for the correct results of
these new `OUTPUT_FORMAT` arguments.
Reviewers: ruiu, atanasyan, grimar, hokein, emaste, espindola
Reviewed By: ruiu
Subscribers: nemanjai, javed.absar, arichardson, krytarowski, kristof.beyls, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D57283
llvm-svn: 352606
Previously we were setting it to the GotPlt output section, which is
incorrect on ARM where this section is in .got. In static binaries
this can lead to sh_info being set to -1 (because there is no .got.plt)
which results in various tools rejecting the output file.
Differential Revision: https://reviews.llvm.org/D57274
llvm-svn: 352413
Summary:
lld discards .gnu.linonce.* sections work around a bug in glibc.
https://sourceware.org/bugzilla/show_bug.cgi?id=20543
Unfortunately, the Linux kernel uses a section named
.gnu.linkonce.this_module to store infomation about kernel modules. The
kernel reads data from this section when loading kernel modules, and
errors if it fails to find this section. The current behavior of lld
discards this section when kernel modules are linked, so kernel modules
linked with lld are unloadable by the linux kernel.
The Linux kernel should use a comdat section instead of .gnu.linkonce.
The minimum version of binutils supported by the kernel supports comdat
sections. The kernel is also not relying on the old linkonce behavior;
it seems to have chosen a name that contains a deprecated GNU feature.
Changing the section name now in the kernel would require all kernel
modules to be recompiled to make use of the new section name. Instead,
rather than discarding .gnu.linkonce.*, let's discard the more specific
section name to continue working around the glibc issue while supporting
linking Linux kernel modules.
Link: https://github.com/ClangBuiltLinux/linux/issues/329
Reviewers: pcc, espindola
Reviewed By: pcc
Subscribers: nathanchance, emaste, arichardson, void, srhines
Differential Revision: https://reviews.llvm.org/D57294
llvm-svn: 352302
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
This does *not* implement full SHT_GROUP semantic, yet it is a simple step forward:
Sections within a group are still considered valid, but they do not behave as
specified by the standard in case of garbage collection.
Differential Revision: https://reviews.llvm.org/D56437
llvm-svn: 352068
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
LLD's performance on PGO instrumented Windows binaries was still not
great even with the fix in D56955; out of the 2m41s linker runtime,
around 2 minutes were still being spent in ICF. I looked into this more
closely and discovered that the vast majority of the runtime was being
spent segregating .pdata sections with the following relocation chain:
.pdata -> identical .text -> unique PGO counter (not eligible for ICF)
This patch causes us to perform 2 rounds of relocation hash
propagation, which allows the hash for the .pdata sections to
incorporate the identifier from the PGO counter. With that, the amount
of time spent in ICF was reduced to about 2 seconds. I also found that
the same change led to a significant ICF performance improvement in a
regular release build of Chromium's chrome_child.dll, where ICF time
was reduced from around 1s to around 700ms.
With the same change applied to the ELF linker, median of 100 runs
for lld-speed-test/chrome reduced from 4.53s to 4.45s on my machine.
I also experimented with increasing the number of propagation rounds
further, but I did not observe any further significant performance
improvements linking Chromium or Firefox.
Differential Revision: https://reviews.llvm.org/D56986
llvm-svn: 351899
It turns out that sections in PGO instrumented object files on Windows
contain a large number of relocations pointing to themselves. With
r347429 this can cause many sections to receive the same hash (usually
zero) as a result of a section's hash being xor'ed with itself.
This patch causes the COFF and ELF linkers to avoid this problem
by adding the hash of the relocated section instead of xor'ing it.
On my machine this causes the regressing test case
provided by Mozilla to terminate in 2m41s.
Differential Revision: https://reviews.llvm.org/D56955
llvm-svn: 351898
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
By default LLD will generate position independent Thunks when the --pie or
--shared option is used. Reference to absolute addresses is permitted in
other cases. For some embedded systems position independent thunks are
needed for code that executes before the MMU has been set up. The option
--pic-veneer is used by ld.bfd to force position independent thunks.
The patch adds --pic-veneer as the option is needed for the Linux kernel
on Arm.
fixes pr39886
Differential Revision: https://reviews.llvm.org/D55505
llvm-svn: 351326
If .rela.iplt does not exist, we used to emit a corrupt symbol table
that contains two symbols, .rela_iplt_{start,end}, pointing to a
nonexisting section.
This patch fixes the issue by setting section index 0 to the symbols
if .rel.iplt section does not exist.
Differential Revision: https://reviews.llvm.org/D56623
llvm-svn: 351218
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
When the range between the source and target of a V7PILongThunk exceeded an
int32 we would trigger a relocation out of range error for the
R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL relocation. This case can happen when
linking the linux kernel as it is loaded above 0xf0000000.
There are two parts to the fix.
- Remove the overflow check for R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL. The
ELF for the ARM Architecture document defines these relocations as having no
overflow checking so the check was spurious.
- Use int64_t for the offset calculation, in line with similar thunks so
that PC + (S - P) < 32-bits. This results in less surprising disassembly.
Differential Revision: https://reviews.llvm.org/D56396
llvm-svn: 350836
The section and offset can be very helpful in diagnosing certian errors.
For example on a relocation overflow or misalignment diagnostic:
test.c:(function foo): relocation R_PPC64_ADDR16_DS out of range: ...
The function foo can have many R_PPC64_ADDR16_DS relocations. Adding the offset
and section will identify exactly which relocation is causing the failure.
Differential Revision: https://reviews.llvm.org/D56453
llvm-svn: 350828
In the PPC64 target we map toc-relative relocations, dynamic thread pointer
relative relocations, and got relocations into a corresponding ADDR16 relocation
type for handling in relocateOne. This patch saves the orignal RelType before
mapping to an ADDR16 relocation so that any diagnostic messages will not
mistakenly use the mapped type.
Differential Revision: https://reviews.llvm.org/D56448
llvm-svn: 350827
Patch by Michael Skvortsov!
This change adds a basic support for linking static MSP430 ELF code.
Implemented relocation types are intended to correspond to the BFD.
Differential revision: https://reviews.llvm.org/D56535
llvm-svn: 350819
ARM and AArch64 use TLS variant 1, where the first two words after the
thread pointer are reserved for the TCB, followed by the executable's TLS
segment. Both the thread pointer and the TLS segment are aligned to at
least the TLS segment's alignment.
Android/Bionic historically has not supported ELF TLS, and it has
allocated memory after the thread pointer for several Bionic TLS slots
(currently 9 but soon only 8). At least one of these allocations
(TLS_SLOT_STACK_GUARD == 5) is widespread throughout Android/AArch64
binaries and can't be changed.
To reconcile this disagreement about TLS memory layout, set the minimum
alignment for executable TLS segments to 8 words on ARM/AArch64, which
reserves at least 8 words of memory after the TP (2 for the ABI-specified
TCB and 6 for alignment padding). For simplicity, and because lld doesn't
know when it's targeting Android, increase the alignment regardless of
operating system.
Differential Revision: https://reviews.llvm.org/D53906
llvm-svn: 350681
Fixes https://bugs.llvm.org/show_bug.cgi?id=40134
addWrappedSymbols() must be called before addReservedSymbols() because the
latter only defines reserved symbols when they are undefined in the symbol
table. If addWrappedSymbols() is called after, then addUndefined() is called
which may lazily pull in more object files that could reference reserved
symbols.
Differential Revision: https://reviews.llvm.org/D56110
llvm-svn: 350251
Sean Fertile