I don't think we have to aim for precise bug compatibility.
We can return a nullptr if a section is consumed by the linker, and
the rest should naturally work.
llvm-svn: 316817
The Android relocation packing format is a more compact
format for dynamic relocations in executables and DSOs
that is based on delta encoding and SLEBs. An overview
of the format can be found in the Android source code:
https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h
This patch implements relocation packing using that format.
This implementation uses a more intelligent algorithm for compressing
relative relocations than Android's own relocation packer. As a
result it can generally create smaller relocation sections than
that packer. If I link Chromium for Android targeting ARM32 I get a
.rel.dyn of size 174693 bytes, as compared to 371832 bytes with gold
and the Android packer.
Differential Revision: https://reviews.llvm.org/D39152
llvm-svn: 316775
This is for PR34852.
GCC 8.0 or earlier have a bug that it emits R_386_GOTPC relocations
against _GLOBAL_OFFSET_TABLE for .debug_info. The bug seems to have
been fixed in 2017: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630,
but we do not want LLD to report errors for such inputs.
In this patch we ignore such relocations.
Differential revision: https://reviews.llvm.org/D38625
llvm-svn: 316761
It was reported (https://reviews.llvm.org/D38724#902841) that when we use
-ffunction-sections --emit-relocs build, REL[A] output section receives the name of first
input section, like .rela.text.first_function_in_text rather than .rela.text.
It is probably not really an issue as sh_info still points to correct target section, but
it does not look clean in output and allows internal section name to leak there,
what at least looks confusing and is not consistent with ld.bfd.
Patch changes this behavior so that target output section name is used as a base.
Differential revision: https://reviews.llvm.org/D39242
llvm-svn: 316760
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
When LLD do ICF for 2 identical sections it leaves 2 duplicate entries in .eh_frame
pointing to the same address. After that it fixes .eh_frame_header's header,
so that it says it contains single FDE, though section itself contains 2
(it contains garbage data at tail).
As a result excessive entries in .eh_frame and excessive dummy data in .eh_frame_header
emited to output. Patch fixes that. This is PR34518.
Differential revision: https://reviews.llvm.org/D38998
llvm-svn: 316648
It is PR34946.
Spec (http://man7.org/linux/man-pages/man1/ld.1.html) tells about
--orphan-handling=MODE, option where MODE can be one of four:
"place", "discard", "warn", "error".
Currently we already report orphans when -verbose given,
what becomes excessive with option implemented.
Patch stops reporting orphans when -versbose is given,
and support "place", "warn" and "error" modes.
It is not yet clear that "discard" mode is useful so it is not supported.
Differential revision: https://reviews.llvm.org/D39000
llvm-svn: 316583
This is PR34886.
SUBALIGN command currently triggers failture if result expression
is zero. Patch fixes the issue, treating zero as 1, what is consistent with
other places and ELF spec it seems.
Patch also adds "is power of 2" check for this and other expressions
returning alignment.
Differential revision: https://reviews.llvm.org/D38846
llvm-svn: 316580
This is "Bug 34836 - --gc-sections remove relocations from --emit-relocs",
When --emit-relocs is used, LLD currently always drops SHT_REL[A] sections from
output if --gc-sections is present. Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D38724
llvm-svn: 316418
r315292 introduced a change that's supposed to consistently ignore
"dead" output sections when placing orphans. Unfortunately, that
change doesn't handle the special case when the orphan section is
second to last section and the last section is dead (e.g. because
it's being discarded) introducing a regression in some cases.
This change handles this case by using the same predicate when
checking the last section.
Differential Revision: https://reviews.llvm.org/D39172
llvm-svn: 316307
The support of R_PPC_ADDR16_HI improves ld compatibility and makes
things on par with RuntimeDyldELF that already implements this
relocation.
Patch by vit9696.
llvm-svn: 316306
The original patch was reported to break a libcxx bot. Unfortunately I
could not reproduce the issue and the bot log is not available anymore.
This patch changes the handling of shared symbols. I will watch the
bot and see it breaks.
Original message:
--------------------------------------------------------------
Handle shared and lazy symbol in the gnu hash construction.
We were not considering those symbols undefined and they could end up
in the end of the dynamic symbol table.
--------------------------------------------------------------
llvm-svn: 316051
The original patch was reported to break a libcxx bot. Unfortunately
I could not reproduce the issue and the bot log is not available anymore.
This patch changes the handling of just lazy symbols. I will watch the
bot and see it breaks.
Original message:
--------------------------------------------------------------
Handle shared and lazy symbol in the gnu hash construction.
We were not considering those symbols undefined and they could end up
in the end of the dynamic symbol table.
--------------------------------------------------------------
llvm-svn: 316004
static __global int Var = 0;
__global int* Ptr[] = {&Var};
...
In this case Var is a non premptable symbol and so its address can be used as the value of Ptr, with a base relative relocation that will add the delta between the ELF address and the actual load address. Such relocations do not require a symbol.
This also fixes LLD which was incorrectly generating a PCREL64 for this case.
Differential Revision: https://reviews.llvm.org/D38910
llvm-svn: 315936
It doesn't make sense to link from an alloc section to a non alloc
one as we were doing.
This matches the behavior of both gold and bfd.
llvm-svn: 315584
Previously we did not support following:
foo = ~0xFF;
and had to add space before numeric value:
foo = ~ 0xFF
That was constistent with ld.bfd < 2.30, which shows:
script.txt:3: undefined symbol `~2' referenced in expression,
but inconsistent with gold.
It was fixed for ld.bfd 2.30 as well:
https://sourceware.org/bugzilla/show_bug.cgi?id=22267
Differential revision: https://reviews.llvm.org/D36508
llvm-svn: 315569
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
This is PR34546.
Currently LLD creates output sections even if it has no input sections,
but its command contains an assignment.
Committed code just assigns the same flag that was used in previous
live section.
That does not work sometimes. For example if we have following script:
.ARM.exidx : { *(.ARM.exidx*) }
.foo : { _foo = 0; } }
Then first section has SHF_LINK_ORDER flag. But section foo should not.
That was a reason of crash in OutputSection::finalize(). LLD tried to calculate
Link value, calling front() on empty input sections list.
We should only keep access flags and omit all others when creating such sections.
Patch fixes the crash observed.
Differential revision: https://reviews.llvm.org/D37736
llvm-svn: 315441
We just don't need one with the current setup.
We only error on undefined references that are used by some
relocation.
If we managed to relax all uses of __tls_get_addr, no relocation uses
it and we don't produce an error.
This is less code and fixes the case were we fail to relax. Before we
would produce a broken output, but now we produce an error.
llvm-svn: 315334
When parsing linker scripts, LLD previously started with a '.' value of 0,
regardless of the internal default image base for the target, and regardless of
switches such as --image-base. It seems reasonable to use a different image base
value when using linker scripts and --image-base is specified, since otherwise the
switch has no effect. This change does this, as well as removing unnecessary
initialisation of Dot where it is not used.
The default image base should not be used when processing linker
scripts, because this will change the behaviour for existing linker script users,
and potentially result in invalid output being produced, as a subsequent assignment
to Dot could move the location counter backwards. Instead, we maintain the existing
behaviour of starting from 0 if --image-base is not specified.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D38360
llvm-svn: 315293
When findOrphanPos does the reverse search to find the OutputSection
preceding the orphan's insertion point, look for a live OutputSection
and ignore "dead" OutputSection's. This matches the behaviour of the
forward search performed earlier in this function.
Added test which without the above fix fails as a result of an orphan
executable section being incorrectly placed in a non-executable segment.
Differential Review: https://reviews.llvm.org/D38690
llvm-svn: 315292
I hadn't synced past the change that changed the default hash style
to --hash-style=both, so my test had the symbols in the wrong order.
llvm-svn: 315119
Dynamic lists in an executable are additive, not restrictive, so we
must continue to export preempted symbols even with a dynamic list.
This fixes sanitizer interception of libc symbols (and should also fix
symbol preemption by users of sanitizers).
Differential Revision: https://reviews.llvm.org/D38647
llvm-svn: 315114
Before this patch we would copy foo into real_foo and wrap_foo into
foo. The net result is that __wrap_foo shows up twice in the symbol
table.
With this patch we:
* save a copy of __real_foo before copying foo.
* drop one of the __wrap_foo from the symbol table.
* if __real_foo was not undefined, add a *new* symbol with that content to
the symbol table.
The net result is that
Anything using foo now uses __wrap_foo
Anything using __real_foo now uses foo.
Anything using __wrap_foo still does.
And the symbol table has foo, __wrap_foo and __real_foo (if defined).
Which I think is the desired behavior.
llvm-svn: 315097
Summary:
These are 16 bit relocations and not part of a HI/LO pair so we need to
check that they don't overflow.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: ruiu, llvm-commits, emaste, sdardis
Tags: #lld
Differential Revision: https://reviews.llvm.org/D38614
llvm-svn: 315073
LLD produces broken .dynamic section when --no-rosegment and at least
one of following options is present:
1) -z rodynamic is given.
2) MIPS target.
That happens because code that writes .dynamic assumes target buffer
is zero-filled, what can be not true after LLD fills it with trap
instructions. With one of two options above, .dynamic becomes
SHF_ALLOC section, so can be affected.
Differential revision: https://reviews.llvm.org/D38580
llvm-svn: 315054
We produce broken output currently.
Code that writes .dynsym assumes output buffer is zero-filled,
though that is not always true. When --no-rosegment is given,
buffer can be filled with trap instructions. Patch fixes the issue.
It is relative with PR34705.
Differential revision: https://reviews.llvm.org/D38579
llvm-svn: 315053
Its PR34712,
GNU linkers recently changed default values to "both" of "sysv".
Patch do the same for all targets except MIPS, where .gnu.hash
section is not yet supported.
Code suggested by Rui Ueyama.
Differential revision: https://reviews.llvm.org/D38407
llvm-svn: 315051