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
Summary:
If a DSO appears more than once with and without --as-needed, ld.bfd and gold consider --no-as-needed to takes precedence over --as-needed. lld didn't and this patch makes it do so.
This makes it a bit away from the position-dependent behavior (how
different occurrences of the same DSO interact) and protects us from
some mysterious runtime errors: if some interceptor libraries add their
own --no-as-needed dependencies (e.g. librt.so), and the user
application specifies -Wl,--as-needed -lrt , the absence of the
DT_NEEDED entry would make dlsym(RTLD_NEXT, "clock_gettime") return NULL
and would break at runtime.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D56089
llvm-svn: 350105
When parsing CU ranges for gdb-index, handle the error (now propagated
up though the API lld is calling here - previously the error was
printed within the libDebugInfo API, not allowing lld to format or
handle the message at all) - including information about the object and
archive name, as well as failing the link.
llvm-svn: 349979
Summary:
For the 2-bit bloom filter, we currently pick the bits Hash%64 and Hash>>6%64 (Shift2=6), but bits [6:...] are also used to select a word, causing a loss of precision.
In this patch, we choose Shift2=26, with is suggested by Ambrose Feinstein.
Note, Shift2 is computed as maskbitslog2 in bfd/elflink.c and gold/dynobj.cc
It is varying with the number of dynamic symbols but we don't
necessarily copy its rule.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55971
llvm-svn: 349966
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
Summary:
In glibc, libc.so is a linker script with an as-needed dependency on ld-linux-x86-64.so.2
GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) )
ld-linux-x86-64.so.2 (as-needed) defines some symbols which resolve undefined references in libc.so.6, it will therefore be added as a DT_NEEDED entry, which isn't necessary.
The test case as-needed-not-in-regular.s emulates the libc.so scenario, where ld.bfd and gold don't add DT_NEEDED for a.so
The relevant code in gold/resolve.cc:
// If we have a non-WEAK reference from a regular object to a
// dynamic object, mark the dynamic object as needed.
if (to->is_from_dynobj() && to->in_reg() && !to->is_undef_binding_weak())
to->object()->set_is_needed();
in_reg() appears to do something similar to IsUsedInRegularObj.
This patch makes lld do the similar thing, but moves the check from
addShared to a later stage MarkLive where all symbols are scanned.
Reviewers: ruiu, pcc, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55902
llvm-svn: 349849
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
Previously, this code printed out an error message like this
ld.lld: error: --reproduce: failed to open /foo: cannot open /foo
Apparently "failed to open /foo:" part is redundant.
llvm-svn: 349571
Previously, if you pass -static to lld, lld searches for only foo.a
and skips foo.so for -lfoo option. However, it didn't reject .so files
if you directly pass their pathnames via the command line, which is a bug.
Differential Revision: https://reviews.llvm.org/D55845
llvm-svn: 349557
Summary:
Other large sections (e.g. .rela.dyn .dynstr) may push .note.* off the
first page. They won't be available in core files if RLIMIT_CORE is
limited.
This patch gives priority to alloctable SHT_NOTE sections so that they
are assuredly in the first page and will be available in core files.
They are small and contain important information (e.g. .note.gnu.build-id
identifies the origin of the core, .note.tag stores NT_FREEBSD_ABI_TAG).
Note: gold Output_section_order has a similar rule:
// Loadable read-only note sections come next so that the PT_NOTE
// segment is on the first page of the executable.
ORDER_RO_NOTE,
Reviewers: ruiu, pcc, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55800
llvm-svn: 349524
The code here wants the output section offset of the instruction
requiring the errata patch, not the virtual address. Without this
change we can end up placing a patch out of range if the virtual
address of the code section is large enough.
Differential Revision: https://reviews.llvm.org/D55732
llvm-svn: 349386
ARM Architecture v6m is used by the smallest microcontrollers such as the
cortex-m0. It is Thumb only (no Thumb 2) which prevents it from using the
existing Thumb 2 range extension thunks as these use the Thumb 2 movt/movw
instructions. Range extension thunks are not usually needed for
microcontrollers due to the small amount of flash and ram on the device,
however if code is copied from flash into ram then a range extension thunk
is required to call that code.
This change adds support for v6m range extension thunks. The procedure call
standard APCS permits a thunk to corrupt the intra-procedural scratch
register r12 (referred to as ip in the APCS). Most Thumb instructions do
not permit access to high registers (r8 - r15) so the thunks must spill
some low registers (r0 - r7) to perform the control transfer.
Fixes pr39922
Differential Revision: https://reviews.llvm.org/D55555
llvm-svn: 349337
Previously we considered R_ARM_V4BX to be an absolute relocation,
which meant that we rejected it in read-only sections in PIC output
files. Instead, treat it as a hint relocation so that relocation
processing ignores it entirely.
Also fix a problem with the test case where it was never being run
because it has a .yaml extension and we don't run tests with that
extension.
Differential Revision: https://reviews.llvm.org/D55728
llvm-svn: 349216
`--plugin-opt=emit-llvm` is an option for LTO. It makes the linker to
combine all bitcode files and write the result to an output file without
doing codegen. Gold LTO plugin has this option.
This option is being used for some post-link code analysis tools that
have to see a whole program but don't need to see them in the native
machine code.
Differential Revision: https://reviews.llvm.org/D55717
llvm-svn: 349198
In the ABI for the 64-bit Arm architecture the section on weak references
states:
During linking, the symbol value of an undefined weak reference is:
- Zero if the relocation type is absolute
- The address of the place if the relocation type is pc-relative.
The relocations associated with an ADRP are relative so we should resolve
the undefined weak reference to the place instead of 0. This matches GNU
ld.bfd behaviour.
fixes pr34928
Differential Revision: https://reviews.llvm.org/D55599
llvm-svn: 349024
This was a missing piece.
We started to print LMAs and information about assignments,
but did not do that for assignments outside of section declarations yet.
The patch implements it.
Differential revision: https://reviews.llvm.org/D45314
llvm-svn: 348468
Sean Fertile