Currently LLD calls the `isMicroMips` routine to determine type of PLT entries
needs to be generated: regular or microMIPS. This routine checks ELF
header flags in the `FirstObj` to retrieve type of linked object files.
So if the first file does not contain microMIPS code, LLD will generate
PLT entries with regular (non-microMIPS) code only.
Ideally, if a PLT entry is referenced by microMIPS code only this entry
should contain microMIPS code, if a PLT entry is referenced by regular
code this entry should contain regular code. In a "mixed" case the PLT
entry can be either microMIPS or regular, but each "cross-mode-call" has
additional cost.
It's rather difficult to implement this ideal solution. But we can
assume that if there is an input object file with microMIPS code, the
most part of the code is microMIPS too. So we need to deduce type of PLT
entries based on finally calculated ELF header flags and do not check
only the first input object file.
This change implements this.
- The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function
called from the `LinkerDriver::link`. Result is stored in
the Configuration::MipsEFlags field.
- The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags`
field to get and check calculated ELF flags.
- New types of PLT records created when necessary.
Differential revision: https://reviews.llvm.org/D37747
llvm-svn: 314675
The result of hash_value(StringRef) depends on sizeof(size_t).
That causes lld to create different mergeable table contents on
32-bit machines.
This patch is to use xxHash64 so that we get the same hash values
on 32-bit machines.
llvm-svn: 314603
String merging is one of the most time-consuming functions in lld.
This patch parallelize it to speed it up. On my 2-socket 20-core
40-threads Xeon E5-2680 @ 2.8 GHz machine, this patch shorten the
clang debug build link time from 7.11s to 5.16s. It's a 27%
improvement and actually pretty noticeable. In this test condition,
lld is now 4x faster than gold.
Differential Revision: https://reviews.llvm.org/D38266
llvm-svn: 314588
This would have found the issues with r313697.
The problem was that that commit mixed the content of different
.eh_frame sections. Unfortunately we had no tests looking inside the
fdes.
llvm-svn: 314433
It was introduced by me in D37059.
Comment was saying that Weak binding is incorrect
for 'foo' symbol and that should be true for symbol in final output.
But at that place LTO temporarily file was checked,
where Weak binding for 'foo' is fine as LTO changes binding for
'LinkerRedefined' symbols internally to prevent IPO.
Binding for 'foo' in final output is correctly set to Global
and that tested just few lines below in the same testcase.
llvm-svn: 314204
When -verbose is specified, patch outputs names of each input orphan section
assigned to output.
Differential revision: https://reviews.llvm.org/D37517
llvm-svn: 314098
Previously when BC file had global variable that was accessed from script,
it was optimized away or inlined by IPO.
In this patch I add symbols at left side of assignment expression as LinkerRedefined,
what prevents optimization for them.
Differential revision: https://reviews.llvm.org/D37059
llvm-svn: 314097
Previously, we had two levels of hash table lookup. The first hash
lookup uses CachedHashStringRefs as keys and returns offsets in string
table. Then, we did the second hash table lookup to obtain GdbSymbol
pointers. But we can directly map strings to GDbSymbols.
One test file is updated in this patch because we no longer have a '\0'
byte at the start of the string pool, which was automatically inserted
by StringTableBuilder.
This patch speeds up Clang debug build (with -gdb-index) link time by
0.3 seconds.
llvm-svn: 314092
For ARM thunks, the `movt` half of the relocation was using an incorrect
offset (it was off by 4 bytes). The original intent seems to have been
for the offset to have been relative to the current instruction, in
which case the difference of 4 makes sense. As the code stands, however,
the offset is always calculated relative to the start of the thunk
(`P`), and so the `movw` and `movt` halves should use the same offset.
This requires a very particular offset between the thunk and its target
to be triggered, and it results in the `movt` half of the relocation
being off-by-one.
The tests here use ARM-Thumb interworking thunks, since those are the
only ARM thunks currently implemented. I actually encountered this with
a range extension thunk (having Peter's patches cherry-picked locally),
but the underlying issue is identical.
Differential Revision: https://reviews.llvm.org/D38112
llvm-svn: 313915
This patch goes back to considering ForceAbsolute in moveAbsRight, but
only if the second argument is not already absolute.
With this we can handle "foo + ABSOLUTE(foo)" and "ABSOLUTE(foo) + foo".
llvm-svn: 313800
The idea of this function is to simplify the implementation of binary
operators like add.
A value might be absolute because of an ABSOLUTE expression, but it
still depends on the value of a section and we might not be able to
evaluate it early. We should keep such values on the LHS, so that we
can delay the evaluation.
We can now handle both "1 + ABSOLUTE(foo)" and "ABSOLUTE(foo) + 1".
llvm-svn: 313794
The previous logic was to try to detect if a linker script defined _gp
by checking !ElfSym::MipsGp->Value. That doesn't work in all cases as
the assigned value can be 0.
We now just always defined it Writer.cpp and always overwrite it
afterwards if needed.
llvm-svn: 313788
Normally to find the offset of a value in a section, we have to
compute the value since the alignment is defined on the final address.
If the alignment is trivial, we can skip the value computation. This
allows us to know the offset even in cases where we cannot yet know
the value.
llvm-svn: 313777
We try to evaluate expressions early when possible, but it is not
possible to evaluate them early if they are based on a section.
Before we would get this wrong on ABSOLUTE expressions.
llvm-svn: 313764
Given a linker script that ends in
.some_sec { ...} ;
__stack_start = .;
. = . + 0x2000;
__stack_end = .;
lld would put orphan sections like .comment before __stack_end,
corrupting the intended meaning.
The reason we don't normally move orphans past assignments to . is to
avoid breaking
rx_sec : { *(rx_sec) }
. = ALIGN(0x1000);
/* The RW PT_LOAD starts here*/
but in this case, there is nothing after and it seems safer to put the
orphan section last. This seems to match bfd's behavior and is
convenient for writing linker scripts that care about the layout of
SHF_ALLOC sections, but not of any non SHF_ALLOC sections.
llvm-svn: 313646
This is PR34506.
Imagine we have 2 sections the same name but different COMDAT groups:
.section .foo,"axG",@progbits,bar,comdat
.section .foo,"axG",@progbits,zed,comdat
When linking relocatable we do not merge SHT_GROUP sections. But still would merge
both input sections .foo into single output section .foo.
As a result we will have 2 different SHT_GROUPs containing the same section, what
is wrong.
Patch fixes the issue, preventing merging SHF_GROUP sections with any others.
Differential revision: https://reviews.llvm.org/D37574
llvm-svn: 313621
We crashed when --emit-relocs was used
and relocated section was collected by GC.
Differential revision: https://reviews.llvm.org/D37561
llvm-svn: 313620
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
_gp points to a position in the file, so it is not really absolute. It
is also simpler to not force it to be absolute, so if there is no
strong ABI requirement we should not do it.
llvm-svn: 313333
This should fix the lto bootstrap.
It is somewhat hard to remember about lazy symbols deep down in the
link. It might be worth it replacing them with undefined symbols once
we are done adding files.
llvm-svn: 313103
https://reviews.llvm.org/rL312796 meant that references to garbage collected common symbols would cause a segfault.
This change fixes the behaviour for references to stripped common symbols.
Differential Revision: https://reviews.llvm.org/D37718
llvm-svn: 313086
For now LLD does not setup the least-significant bit for microMIPS
symbols. llvm-objdump does not like that. In attempt to fix
sanitizer-x86_64-linux-fast build-bot let's temporarily check the raw
binary file content.
llvm-svn: 313040
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
When given
foobar = ALIGN(., 0x100);
my expectation from what the manual says is that the final address of
foobar will be aligned. It seems that bfd aligns the offset in the
section, which causes some odd results if the section is not 0x100
aligned. Gold aligns the address.
This changes lld to align the final address.
llvm-svn: 312979
'@' is a valid character in file paths, but the linker script tokenizer treats it
as a separate token. This was leading to an unexpected test failure, on our local
builds. This patch changes the test to quote the path to prevent this happening.
An alternative would have been to add '@' to the list of "unquoted tokens" in
ScriptLexer.cpp, but ld.bfd has the same behaviour as the current LLD.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D37689
llvm-svn: 312922
This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and
--dynamic-list controls which of those are preemptible.
Unlike previous versions, undefined symbols are still considered
preemptible, which was the issue breaking the cfi tests.
This fixes pr34053.
llvm-svn: 312806
to separate commons based on file name patterns. The following linker script
construct does not work because commons are allocated before section placement
is done and the only synthesized BssSection that holds all commons has no file
associated with it:
SECTIONS { .common_0 : { *file0.o(COMMON) }}
This patch changes the allocation of commons to create a section per common
symbol and let the section logic do the layout.
Differential revision: https://reviews.llvm.org/D37489
llvm-svn: 312796
There is no need to check anything excepr that
symbol is not in output.
Previously additional iformation like symbol values
or flags were checked, that was not correct.
For example if we would provide symbol with different
value/visibility/type for case when should not provide
symbol at all, testcase would not fail.
llvm-svn: 312779
REGION_ALIAS(alias, region)
Alias names can be added to existing memory regions created with
the MEMORY command. Each name corresponds to at most one
memory region.
Differential revision: https://reviews.llvm.org/D37477
llvm-svn: 312777
If --dynamic-list is given, only those symbols are preemptible.
This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and --dynamic-list
controls which of those are preemptible.
This fixes pr34053.
llvm-svn: 312757
To support errata patching on AArch64 we need to be able to overwrite
an arbitrary instruction with a branch. For AArch64 it is sufficient to
always write all the bits of the branch instruction and not just the
immediate field. This is safe as the non-immediate bits of the branch
instruction are always the same.
Differential Revision: https://reviews.llvm.org/D36745
llvm-svn: 312727
The default padding for an executable segment is the target trap
instruction which for x86_64 is 0xCC. However, the .eh_frame section
requires the padding to be zero. The code that writes the .eh_frame
section assumes that its segment is zero initialized and does not
explicitly write the zero padding. This does not work when the .eh_frame
section is in the executable segment (for example when using
-no-rosegment).
This patch changes the .eh_frame writing code to explicitly write the
zero padding.
Differential Revision: https://reviews.llvm.org/D37462
llvm-svn: 312706
If using --format=binary with an input file name that has one or more non-ascii
characters in, LLD has undefined behaviour (it crashes on my Windows Debug build)
when calling isalnum with these non-ascii characters. Instead, of calling
std::isalnum, this patch uses an internal version that ignores the locale and
checks a specific subset of characters.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D37331
llvm-svn: 312705
The R_AARCH64_LDST<N>_ABS LO12_NC relocations where N is 8, 16, 32, 64 or
128 have a scaled immediate. For example R_AARCH64_LDST32_ABS_LO12_NC
shifts the calculated value right by 4. If the target symbol + relocation
addend is not aligned properly then bits of the answer will be lost.
This change adds an alignment check to the relocations to make sure the
target of the relocation is aligned properly. This matches the behavior of
GNU ld. The motivation is to catch ODR violations such as a declaration of
extern int foo, but a definition of bool foo as the compiler may use
R_AARCH64_LDST32_ABS_LO12_NC for the former, but not align the destination.
Differential Revision: https://reviews.llvm.org/D37444
llvm-svn: 312637
The --symbol-ordering-file path was not being rewritten in the response file when
using --reproduce. This patch adds this to the list of switches that are rewritten,
so that the path is somewhere within the reproducer directory tree.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D37480
llvm-svn: 312626
Previously LLD did not calculate LMAOffset correctly when
AT and MEMORY were used together.
Patch fixes PR34407.
Differential revision: https://reviews.llvm.org/D37469
llvm-svn: 312625
Recently (before r312477) lib/DebugInfo incorrectly handled the case
when debug ranges uses base address of CU. Section index was not
calulcated properly and LLD crashed on provided testcase.
Differential revision: https://reviews.llvm.org/D37297
llvm-svn: 312478
The problem with symbol assignments in implicit linker scripts is that
they can refer synthetic symbols such as _end, _etext or _edata. The
value of these symbols is currently fixed only after all linker script
commands are processed, so these assignments will be using non-final and
hence invalid value.
Rather than fixing the symbol values after all command processing have
finished, we instead change the logic to generate symbol assignment
commands that set the value of these symbols while processing the
commands, this ensures that the value is going to be correct by the time
any reference to these symbol is processed and is equivalent to defining
these symbols explicitly in linker script as BFD ld does.
Differential Revision: https://reviews.llvm.org/D36986
llvm-svn: 312305
Imagine we have archive file with symbols foo and bar.
And script that do foo = 1.
In that case correct behavior is not to fetch symbols from archive but
create absolute symbol.
If we have script zed = foo then symbol foo will be fetched from archive.
Currently we have Opt.ReferencedSymbols list of symbols referenced
by script and create them undefined early. That allows archives fetching logic
to work. That is what LLD already do and it seems everything is fine here.
But during writing D37059 I had to add left side of assignments to
Opt.ReferencedSymbols list because wanted to stop optimizing out
these symbols when LTO is involved (LTO also uses this list).
And testcase from this patch would have fail if we would have it before.
Differential revision: https://reviews.llvm.org/D37208
llvm-svn: 312004
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
linker script SECTION rules. This patch extends it to use a fully specified
file name as it appears in --trace output to match agains, i.e,
"<path>/<objname>.o" or "<path>/<libname>.a(<objname>.o)".
Differential Revision: https://reviews.llvm.org/D37031
llvm-svn: 311713
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
Currently, LLD checks whether there's enough space for headers by
checking if headers fit below the address of the first allocated
section. However, that's always thue if the binary doesn't start
at zero which means that LLD always emits a segment for headers,
even if no other sections belong to that segment.
This is a problem in cases when linker script is being used with a
non-zero start address when we don't want to make the headers visible
by not leaving enough space for them. This pattern is common in
embedded programming but doesn't work in LLD.
This patch changes the behavior of LLD in case when linker script
is being to match the behavior of BFD ld and gold, which is to only
place headers into a segment when they're covered by some output
section.
Differential Revision: https://reviews.llvm.org/D36256
llvm-svn: 311586
Previously up to 3 errors were reported at once,
with patch we always will report only one,
just like in other linker code.
Differential revision: https://reviews.llvm.org/D37015
llvm-svn: 311537
It was broken from begining, because visibility
attributes were not applied properly to
symbols before this patch.
Differential revision: https://reviews.llvm.org/D36966
llvm-svn: 311536
Code suggested by Rui Ueyama in PR34238 comments.
Previously LTO optimized away symbols referenced from linker script
because did not see that them are used from regular objects.
Patch adds such symbols as undefined earlier, before running LTO,
what sets IsUsedInRegularObj for them and fixes the issue.
Differential revision: https://reviews.llvm.org/D37009
llvm-svn: 311534
Patch by Rafael Espíndola.
This is PR34053.
The implementation is a bit of a hack, given the precise location where
IsPreemtible is set, it cannot be used from
SymbolTable::handleAnonymousVersion.
I could add another method to SymbolTable if you think that would be
better.
Differential Revision: https://reviews.llvm.org/D36499
llvm-svn: 311468
This is PR33097.
Previously when doing relocatable link, all IR symbols were absent
in result object file. Patch makes external symbols to be exported.
Differential revision: https://reviews.llvm.org/D36957
llvm-svn: 311431
hexdump is not part of the GNU coreutils, and so is not required to be able to
build and test LLVM, according to the documentation. This change removes the
dependency on hexdump from a lit test.
Reviewers: grimar
Differential Revision: https://reviews.llvm.org/D36958
llvm-svn: 311335
With fix: explicitly specify ouput format for hexdump tool call.
Original commit message:
[ELF] - Do not forget to fill last bytes of PT_LOADs with trap instructions.
Previously last 4 bytes of executable loads
were not filled with trap instructions,
patch fixes this bug.
Differential revision: https://reviews.llvm.org/D36262
llvm-svn: 311315
Previously we would crash on samples from testcase,
because were trying to access zero pointer to output section.
Differential revision: https://reviews.llvm.org/D36145
llvm-svn: 311311
Previously last 4 bytes of executable loads
were not filled with trap instructions,
patch fixes this bug.
Differential revision: https://reviews.llvm.org/D36262
llvm-svn: 311310
We would previously crash on next script:
MEMORY { name : ORIGIN = .; }
Patch fixes that.
Differential revision: https://reviews.llvm.org/D36138
llvm-svn: 311073
This is relative to PR30720.
Previously we ignored all --plugin-opt arguments.
Patch adds support for them.
Patch does not add any new LTO options,
and just implements mapping from --plugin-opt to existent ones.
Differential revision: https://reviews.llvm.org/D36227
llvm-svn: 310826
This is PR33886,
previously we did not output common symbols to map,
patch fixes that.
Differential revision: https://reviews.llvm.org/D36466
llvm-svn: 310703
Liveness is usually a notion of input sections, but this patch adds
"liveness" bit to common symbols because they don't belong to any
input section.
This patch is based on https://reviews.llvm.org/D36520
Differential Revision: https://reviews.llvm.org/D36546
llvm-svn: 310617
Summary: This small patch adds the support for ! operator in linker scripts.
Reviewers: ruiu, rafael
Reviewed By: ruiu
Subscribers: meadori, grimar, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D36451
llvm-svn: 310607
GC code contains following logic uncovered by tests:
for (StringRef S : Config->Undefined)
MarkSymbol(Symtab->find(S));
As far I can tell we never had test for that before,
patch fixes it.
Differential revision: https://reviews.llvm.org/D36519
llvm-svn: 310556
Emit these symbols as long as we're building in a static configuration,
even if we're emitting a dynamic symbol table. This is consistent with
both bfd and gold.
Ordinarily, the combination of -static and -export-dynamic wouldn't make
much sense. Unfortunately, cmake versions prior to 3.4 forcefully
injected -rdynamic [1], so it seems worthwhile to support.
[1] https://cmake.org/cmake/help/v3.4/policy/CMP0065.html
Differential Revision: https://reviews.llvm.org/D36350
llvm-svn: 310168
D35945 introduces change when there is useless to check Error flag
in few places, but ErrorCount must be checked instead.
But then we probably can just check ErrorCount always. That should simplify
things. Patch do that.
Differential revision: https://reviews.llvm.org/D36266
llvm-svn: 310046
This is PR33889,
Patch adds support of combination of linkerscript and
-symbol-ordering-file option.
If no sorting commands are present in script inside section declaration
and no --sort-section option specified, code uses sorting from ordering
file if any exist.
Differential revision: https://reviews.llvm.org/D35843
llvm-svn: 310045
Following r309829, if a string table appears in an executable segment, the strings
will not be null terminated. This is a problem, for example, for the .dynstr
section when using -no-rosegment. The strings end up being terminated with 0xcc
because prior to this patch, LLD did not explicitly write the null terminators.
This change fixes that by always writing the null terminators.
Reviewers: rafael
Differential Revision: https://reviews.llvm.org/D36267
llvm-svn: 310042
Following possible scripts triggered accessing to Target when it was not yet
initialized (was nullptr).
MEMORY { name : ORIGIN = DATA_SEGMENT_RELRO_END; }
MEMORY { name : ORIGIN = CONSTANT(COMMONPAGESIZE); }
Patch errors out instead.
Differential revision: https://reviews.llvm.org/D36140
llvm-svn: 309953
When the data segment is the last segment, it is correct to leave
it unaligned. However, when the code segment is the last segment,
it should be aligned to the page boundary to avoid loading the
non-segment parts of the ELF file at the end of the file.
Differential Revision: https://reviews.llvm.org/D33630
llvm-svn: 309829
With fix for undefined weak symbols in executable.
Original commit message:
This is PR32112. Previously when we linked executable with
--unresolved-symbols=ignore-all and undefined symbols, like:
_start:
callq und@PLT
we did not create relocations, though it looks in that case
we should delegate handling of such symbols to runtime linker,
hence should emit them. Patch fixes that.
Differential revision: https://reviews.llvm.org/D35724
llvm-svn: 309796
Before we were doing it with --export-dynamic. That seems incorrect.
The intention of --export-dynamic is to export symbols *defined* in
the executable.
llvm-svn: 309605
Previously we would crash when tried to ALIGN(0).
Patch uses value 1 instead in this case, that
looks to be consistent with GNU linkers
and reasonable and simple behavior itself.
Differential revision: https://reviews.llvm.org/D35942
llvm-svn: 309372
This is PR32112. Previously when we linked executable with
--unresolved-symbols=ignore-all and undefined symbols, like:
_start:
callq und@PLT
we did not create relocations, though it looks in that case
we should delegate handling of such symbols to runtime linker,
hence should emit them. Patch fixes that.
Differential revision: https://reviews.llvm.org/D35724
llvm-svn: 309252
With this we only ask LTO to keep a C named section if there is a
__start_ or __end symbol.
This is not as strict as lld's --gc-sections, but is as good as we can
get without having a far more detailed ir summary.
llvm-svn: 309232
This patch fixes a small issue with respect to how memory region names
are parsed on output section descriptions. For example, consider:
.text : { *(.text) } > rom
That can also be written like:
.text : { *(.text) } >rom
The latter form is accepted by GNU LD and is fairly common.
Differential Revision: https://reviews.llvm.org/D35920
llvm-svn: 309191
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 is PR30422,
previously LLD did not render all option aliases in --help.
With this patch it will.
Differential revision: https://reviews.llvm.org/D35477
llvm-svn: 309089
Previously .init_array/.fini_array sections
were not unique and we had 3 .init_array sections +
3 .fini_array input sections passed to linker,
instead of 5 + 5.
Differential revision: https://reviews.llvm.org/D35552
llvm-svn: 308958
This is PR33714.
Previously for each input section offset of memory region
was incremented on a size of output section.
That resulted in a wrong error message saying about
overflow. Patch fixes that.
Differential revision: https://reviews.llvm.org/D35803
llvm-svn: 308955
We do this emitting a section for every function when LTO is used.
Fixes PR33888.
Differential Revision: https://reviews.llvm.org/D35809
llvm-svn: 308915
Eq helper allows to define `XXX` and `XXX=` options forms easily.
Patch adds testcases for few aliases.
Differential revision: https://reviews.llvm.org/D35619
llvm-svn: 308752
Also add the test cases for the addition and subtraction both for
the relative and absolute case.
Differential Revision: https://reviews.llvm.org/D35346
llvm-svn: 308692
We were not looking at Repl and so thinking there was no output
section associated with the merged symbol. Because of that it was
produced as absolute.
This was found by an internal round of testing.
llvm-svn: 308681
Summary:
If the linker is invoked with `--chroot /foo` and `/bar/baz.o`, it
tries to read the file from `/foo/bar/baz.o`. This feature is useful
when you are dealing with files created by the --reproduce option.
Reviewers: grimar
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35517
llvm-svn: 308646
With that in place we can use lld's own infrastructure for the low
level detail of dwarf parsing.
With this we don't decompress sections twice, we don't scan all
realocations and even with this simplistic implementation linking
clang with gdb index goes from 34.09 seconds to 20.80 seconds.
llvm-svn: 308544
In addition this includes a change to prefer symbols with a default
version @@ over unversioned symbols.
Original commit message:
[ELF] - Handle symbols with default version early.
This fixes last testcase provided in PR28414.
In short issue is next: when we had X@@Version symbol in object A,
we did not resolve it to X early. Then when in another object B
we had reference to undefined X, symbol X from archive was fetched.
Since both archive and object A contains another symbol Z, duplicate
symbol definition was triggered as a result.
Correct behavior is to use X@@Version from object A instead and do not fetch
any symbols from archive.
Differential revision: https://reviews.llvm.org/D35059
llvm-svn: 308492
Noticed while testing for an out of tree target. There are probably more tests that should be so marked.
I'm not sure who owns these tests so I've added a few names I recognise from the recent history.
With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all!
Differential Revision: https://reviews.llvm.org/D34685
llvm-svn: 308335
This is PR33766.
-F name
--filter=name
When creating an ELF shared object, set the internal DT_FILTER field to the specified name. This tells the dynamic linker that the symbol table of the shared object which is being created should be used as a filter on the symbol table of the shared object name.
If you later link a program against this filter object, then, when you run the program, the dynamic linker will see the DT_FILTER field. The dynamic linker will resolve symbols according to the symbol table of the filter object as usual, but it will actually link to the definitions found in the shared object name. Thus the filter object can be used to select a subset of the symbols provided by the object name.
(https://linux.die.net/man/1/ld).
Shared Objects as Filters:
https://docs.oracle.com/cd/E19683-01/817-3677/chapter4-31738/index.html
Differential revision: https://reviews.llvm.org/D35352
llvm-svn: 308167
Previously we used precompiled objects in gdb-index.s and
debug-gnu-pubnames.s testcases. We can avoid that.
Differential revision: https://reviews.llvm.org/D35360
llvm-svn: 308005
In filling the .got sections, InputSection::OutSecOff was added twice
when finding the position to apply a relocation: first time in
InputSection::writeTo() and then in SectionBase::getOffset().
Differential revision: https://reviews.llvm.org/D34232
llvm-svn: 308003
This was previously erroring out if one of the dead symbols was a
TLS symbol and we were able to discard all TLS sections.
Differential Revision: https://reviews.llvm.org/D35397
llvm-svn: 307984
PT_TLS is a type of program header, so we wouldn't expect to see
one in an object file. This error should probably be referring to
the fact that we didn't see a section with the flag SHF_TLS, which
would normally cause us to create a PT_TLS program header.
Differential Revision: https://reviews.llvm.org/D35395
llvm-svn: 307983
Patch removes restriction about moving location counter
backwards outside of output sections declarations.
That may be useful for some apps relying on such scripts,
known example is linux kernel.
Differential revision: https://reviews.llvm.org/D34977
llvm-svn: 307794
This fixes PR33712.
Imagine following script and code:
VER1 { global: foo; local: *; };
VER2 { global: foo; };
.global bar
bar:
.symver bar, foo@VER1
.global zed
zed:
.symver zed, foo@@VER2
We add foo@@VER2 as foo to symbol table, because have to resolve references to
foo for default symbols.
Later we are trying to assign symbol versions from script. For that we are searching for 'foo'
again. Here it is placed under VER1 and VER2 at the same time, we find it twice and trying to
set version again both times, hence LLD shows a warning.
Though sample code is correct: we have 2 different versions of foo.
Patch gives a symbol version extracted from name a priority over version set by script.
Differential revision: https://reviews.llvm.org/D35207
llvm-svn: 307792
When version script was used, binding opf undefined weak symbols sometimes
was calculated as STB_LOCAL, making them non-preemtible what
broke correct relocations handling logic for them.
Fixes PR33738.
Differential revision: https://reviews.llvm.org/D35263
llvm-svn: 307767
It was intially implemented in D19517 but then broken.
Patch fixes PR33707, testcase is based on PR's case.
Differential revision: https://reviews.llvm.org/D35119
llvm-svn: 307652
This is relative to PR33173,
Previously if something wrong happened on DWARF parsers side during parsing
object for building gdb index (like was in PR: unsupported relocation)
then LLD continued and finished the link. DWARF parsers sure showed error
message on their side, but that is all.
Patch changes behavior to fail the link in this case and show more
detailed message.
Differential revision: https://reviews.llvm.org/D34814
llvm-svn: 307370
This fixes last testcase provided in PR28414.
In short issue is next: when we had X@@Version symbol in object A,
we did not resolve it to X early. Then when in another object B
we had reference to undefined X, symbol X from archive was fetched.
Since both archive and object A contains another symbol Z, duplicate
symbol definition was triggered as a result.
Correct behavior is to use X@@Version from object A instead and do not fetch
any symbols from archive.
Differential revision: https://reviews.llvm.org/D35059
llvm-svn: 307364
This is PR28414.
Previously LLD was unable to link following:
(failed with undefined symbol bar)
Version script:
SOME_VERSION { global: *; };
.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
jmp bar
Manual has next description:
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename.
The difference is name2@@nodename will also be used to resolve references to name2 by the linker
https://sourceware.org/binutils/docs/as/Symver.html
Patch implements that. If we have name@@ver symbol and name is undefined, name@@ver is used to resolve references to name.
If name is defined then multiple definition error is emited, that is consistent with what bfd do.
Differential revision: https://reviews.llvm.org/D33680
llvm-svn: 307077
Script commands are processed before unused synthetic sections are
removed. Therefore, if a linker script matches one of these sections
it'll get emitted as an empty output section because the logic for
removing unused synthetic sections ignores script commands which
could have already matched and captured one of these sections. This
patch fixes that by also removing the unused synthetic sections from
the script commands.
Differential Revision: https://reviews.llvm.org/D34800
llvm-svn: 307037
Since yaml2obj is now able to parse integer values as relocation types,
there is no need to keep hex edited elf object for this test,
we can produce it on fly, just like this patch do.
Differential revision: https://reviews.llvm.org/D34893
llvm-svn: 307032
This patch makes changes to allow sections without the SHF_ALLOC bit to be
assigned to segments in a linker script.
The assignment of output sections to segments is performed in
LinkerScript::createPhdrs. Previously, this function would bail as soon as it
encountered an output section which did not have the SHF_ALLOC bit set, thus
preventing any output section without SHF_ALLOC from being assigned to a
segment.
This restriction has now been removed from LinkerScript::createPhdrs and instead
a check for SHF_ALLOC has been added to LinkerScript::adjustSectionsAfterSorting
to not propagate program headers to sections without SHF_ALLOC which matches the
behaviour of bfd linker scripts.
Differential Revision: https://reviews.llvm.org/D34204
llvm-svn: 307013
This is PR28414.
Previously LLD was unable to link following:
(failed with undefined symbol bar)
```
Version script:
SOME_VERSION { global: *; };
.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
jmp bar
```
Manual has next description:
//
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename.
**The difference is name2@@nodename will also be used to resolve references to name2 by the linker**
https://sourceware.org/binutils/docs/as/Symver.html
//
Patch implements that. If we have name@@ver symbol and name is undefined,
name@@ver is used to resolve references to name.
Differential revision: https://reviews.llvm.org/D33680
llvm-svn: 306813
Add support for the most common SPARC relocations.
Make DT_PLTGOT point to the PLT on SPARC.
Mark the PLT as executable on SPARC.
This adds a basic test that creates a SPARV9 executable
that invokes the exit system call on OpenBSD.
Patch by Mark Kettenis.
Differential Revision: https://reviews.llvm.org/D34618
llvm-svn: 306565
This is PR33596. Previously LLD would crash
because BYTE command synthesized output section,
but it was not assigned to Sec member of OutputSectionCommand.
Behaviour of -script and -r combination is not well defined,
but it seems after this change LLD naturally inherits behavior of
GNU linkers - creates output section requested in script and does not
crash anymore.
Differential revision: https://reviews.llvm.org/D34676
llvm-svn: 306527
This fixes PR33598.
Size field for undefined symbols is not significant.
Setting it to fixed value, like zero, may be useful though.
For example when we have 2 DSO's, like in this PR, if lower level DSO may
change slightly (in part of some symbol's st_size) and higher-level DSO is
rebuilt, then tools that monitoring checksum of high level DSO file can notice
it and trigger cascade of some other unnecessary actions.
If we set st_size to zero, that can be avoided.
Differential revision: https://reviews.llvm.org/D34673
llvm-svn: 306526
When -ffunction-sections and ARM C++ exceptions are used each .text.suffix
section will have at least one .ARM.exidx.suffix section and may have an
additional .ARM.extab.suffix section if the unwinding instructions are too
large to inline into the .ARM.exidx table entry. For a large program without
a linker script this can lead to a large number of section header table
entries that can increase the size of the ELF file.
This change introduces a default rule for .ARM.extab.* to be placed in
a single output section called .ARM.extab . This follows the behavior of
ld.gold and ld.bfd.
fixes pr33407
Differential Revision: https://reviews.llvm.org/D34678
llvm-svn: 306522
It is somewhat pointless to check that a specific error is not
produced. That is already checked by the ld.lld exit value.
Instead make the test a bit stronger by checking that the output file
has the expected symbol and section.
llvm-svn: 306496
This patch fills holes in executable sections with 0xd4 (ARM) or
0xef (MIPS). These trap instructions were suggested by Theo de Raadt.
llvm-svn: 306322
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
This is useful when an upper limit on the cache size needs to be
controlled independently of the amount of the amount of free space.
One use case is a machine with a large number of cache directories
(e.g. a buildbot slave hosting a large number of independent build
jobs). By imposing an upper size limit on each cache directory,
users can more easily estimate the server's capacity.
Differential Revision: https://reviews.llvm.org/D34547
llvm-svn: 306126
Previously, when symbol A is renamed B, both A and B end up having
the same name. This is because name is a symbol's attribute, and
we memcpy symbols for symbol renaming.
This pathc saves the original symbol name and restore it after memcpy
to keep the original name.
This patch shouldn't change program's meaning, but names in symbol
tables make more sense than before.
llvm-svn: 306036
The --exclude-libs option is not a popular option, but at least some
programs in Android depend on it, so it's worth to support it.
Differential Revision: https://reviews.llvm.org/D34422
llvm-svn: 305920
I found this while trying to build u-boot. It uses -Ttext in
combination with linker scripts.
My first reaction was to change the linker scripts to have the correct
value, but I found that it is actually quite convenient to have -Ttext
take precedence.
By having just
.text : { *(.text) }
In the script, they can define the text address in a single Makefile
and pass it to ld with -Ttext and for the C code with
-DFoo=value. Doing the same with linker scripts would require them to
be generated during the build.
llvm-svn: 305766
This patch adds support for segment NONE in linker scripts which enables the
specification that a section should not be assigned to any segment.
Note that GNU ld does not disallow the definition of a segment named NONE, which
if defined, effectively overrides the behaviour described above. This feature
has been copied.
Differential Revision: https://reviews.llvm.org/D34203
llvm-svn: 305700
In r305364, Rui changed the mechanism that parses -z option values slightly.
This caused a bug, as demonstrated by this test, which now fails:
---
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
# RUN: ld.lld %t.o -o %t -z max-page-size
.global _start
_start:
nop
---
Before, the link succeeded and set the max-page-size to the target default.
After we get the following two error messages:
"invalid max-page-size: "
"max-page-size: value isn't a power of 2"
The latter error is because an uninitialised variable ends up being passed back
to getMaxPageSize).
This change ensures we only get the first error.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D34234
llvm-svn: 305679
This is necessary to ensure that sections containing symbols referenced
from linker scripts (e.g. in data commands) don't get GC'd.
Differential Revision: https://reviews.llvm.org/D34195
llvm-svn: 305452
Currently we do layout as if non alloc sections had an actual address
and then set it to zero. This produces a few odd results where a
symbol has an address that is inconsistent with the section address.
The simplest way to fix it is probably to just set the address earlier.
The behavior of bfd seems to be similar, but it only sets the non
alloc section address is missing from the linker script or if the
script has an explicit " : 0" setting the address of the output
section (which the default script does).
llvm-svn: 305323
This shows an oddity of this output. While the section address is 0,
the the symbol address is computed as if the section was allocatable.
llvm-svn: 305250
The ELF standard defines that the SHT_GROUP section as follows:
- its sh_link has the symbol index, and
- the symbol name is used to uniquify section groups.
Object files created by GNU gold does not seem to comply with the
standard. They have this additional rule:
- if the symbol has no name and a STT_SECTION symbol, a section
name is used instead of a symbol name.
If we don't do anything for this, the linker fails with a mysterious
error message if input files are generated by gas. It is unfortunate
but I think we need to support it.
Differential Revision: https://reviews.llvm.org/D34064
llvm-svn: 305218
Given
.weak target
.global _start
_start:
b target
The intention is that the branch goes to the instruction after the
branch, effectively turning it on a nop. The branch adds the runtime
PC, but we were adding it statically too.
I noticed the oddity by inspection, but llvm-objdump seems to agree,
since it now prints things like:
b #-4 <_start+0x4>
llvm-svn: 305212
Relocations referring to merge sections are considered equal if they
resolve to the same offset in the same output section.
Differential Revision: https://reviews.llvm.org/D34094
llvm-svn: 305177
Currently the freebsd early boot code fails to link. The issue reduces
to 16 bit code at position 0x7000 wanting to jump to position
0x9000. That is represented in the .o file as a relocation with no
symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip
after the current instruction for jumps).
If the addend is interpreted as signed (it should), it is -28674. In a
32 bit architecture, that is the address 0xffff8ffe. To get there from
0x7000 we have to add 4294909950 (too big) or subtract 57346 (too
small). We then produce an error.
What lld is missing is the fact that at runtime this will actually be
a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the
correct result in 16 bits (-28674).
Since we have a 16 bit addend and a 16 bit PC, the relocation can move
the PC to any 16 bit address and that is the only thing we really need
to check: if the address we are pointing to fits in 16 bits. This is
unfortunately hard to do since we have to delay subtracting the PC and
if we want to do that outside of Target.cpp, we have to move the
overflow check out too. An incomplete patch that tries to do that is
at https://reviews.llvm.org/D34070
This patch instead just relaxes the check. Since the value we have is
the destination minus the PC and the PC is 16 bits, it should fit in
17 bits if the destination fits in 16 too.
bfd had a similar issue for some time and got a similar fix:
https://sourceware.org/ml/binutils/2005-08/msg00001.html
llvm-svn: 305135
SHF_GROUP bit doesn't make sense in executables or DSOs, so linkers are
expected to remove that bit from section flags. We did that when we create
output sections.
This patch is to do that earlier than before. Now the flag is dropped when
we instantiate input section objects.
This change improves ICF. Previously, two sections that differ only in
SHF_GROUP flag were not merged, because when the control reached ICF,
the flag was still there. Now the flag is dropped before reaching to ICF,
so the difference is ignored naturally.
This issue was found by pcc.
Differential Revision: https://reviews.llvm.org/D34074
llvm-svn: 305134
This is used by linux kernel build system.
(https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt "3.2 Built-in object goals")
It has for example next configuration for linking built-in.o files:
drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y))
drivers-$(CONFIG_PCI) += arch/ia64/pci/
...
drivers-$(CONFIG_OPROFILE) += arch/ia64/oprofile/
Im most simple case all CONFIG_* options are off. That means linker is called with empty input archive,
emulation option and no inputs and expected to generate some relocatable output.
ld.bfd is able to do that, we dont.
Patch allows to support this case.
Differential revision: https://reviews.llvm.org/D33937
llvm-svn: 305069
Igor Kudrin