This generalizes the old heuristic placing SHT_DYNSYM SHT_DYNSTR first in the readonly SHF_ALLOC segment.
Reviewers: espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D48406
llvm-svn: 335674
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
Summary:
Currently when --no-rosegment is specified or a linker script with SECTIONS command is used,
.rodata (A) .text (AX) are assigned the same rank and .rodata may be placed after .text .
This increases the gap between .text and .bss and can cause pc-relative relocation overflow (e.g. gcc crtbegin.o crtbegin.S have R_X86_64_PC32 relocation from .text to .bss).
This patch makes SingleRoRx affect only segment layout, not section layout. As a consequence, .rodata will be placed before .text regardless of SingleRoRx.
Reviewers: espindola, ruiu, grimar, echristo, javed.absar
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D48405
llvm-svn: 335627
rLLD329787 added the stable sorting to SymbolTableBaseSection::postThunkContents.
I profiled the Mozilla (response-O0.txt) from lld-speed-test package and found
std::stable_sort is showing up in profile results and consuming the 3.1% of the total
CPU time in the RelWithDebug build. Total time of postThunkContents is 3.54%, 238ms.
This change reduces postTimeContents time to 50ms, making it to take 0.73% of Total CPU time.
So, instead of sorting the local part I suggest to just rebuild it.
That is what this patch does.
Differential revision: https://reviews.llvm.org/D45519
llvm-svn: 335583
* Move `REQUIRES:` line to the top
* llvm-mc ... -o %t -> llvm-mc ... -o %t.o
* Don't check "TEXT" "DATA" columns (they are bfd-style names that do
not fit into llvm well) in llvm-objdump output
llvm-svn: 335498
ICF is able to merge sections which relocations referring regular input sections
or mergeable sections, so it handles InputSection and MergeInputSection cases.
The following "return false" line which is executed in case of another type
of the sections is uncovered by our test cases:
https://github.com/llvm-mirror/lld/blob/master/ELF/ICF.cpp#L285
Patch fixes code coverage for this place.
llvm-svn: 335482
This test case check that ICF does not merge 2 sections which relocations
efer to symbols that live in sections of the different types
(regular input section and mergeable input sections in this case).
It covers the following line of code, which was uncovered previously:
https://github.com/llvm-mirror/lld/blob/master/ELF/ICF.cpp#L271
llvm-svn: 335475
Code is dead. We use only InputSections when building the list of
sections elegible for the ICF:
https://github.com/llvm-mirror/lld/blob/master/ELF/ICF.cpp#L439
And 'isEligible' filters out SyntheticSections as well for us.
That way the only Kind we have in the Sections vector is SectionBase::Regular,
so we do not need to check sections kind at all, it is always the same.
llvm-svn: 335460
This caused a lot of issues on the WebAssembly waterfall.
In particular, until with the signature of `main`. We
probably want a better solution for main before we re-land.
Reverts rL335192
llvm-svn: 335355
--verbose is not used to report ICF sections since r324755,
--print-icf-sections is used instead.
These tests were at fact disabled since that time.
llvm-svn: 335354
Change removes the excessive comparsion of
the relocation arrays sizes.
This code was dead, because at the higer level,
equalsConstant function contains the following check:
`A->NumRelocations != B->NumRelocations`
where NumRelocations contains the size of the relocations array.
So removed check did the same job twice.
This was found with use of code coverage analysis.
llvm-svn: 335346
During symbol resolution, emit warnings for function signature
mismatches. During GC, if any mismatched symbol is marked as live
then generate an error.
This means that we only error out if the mismatch is written to the
final output. i.e. if we would generate an invalid wasm file.
Differential Revision: https://reviews.llvm.org/D48394
llvm-svn: 335192
While building a Global Offset Table try to fill the primary GOT as much
as possible because the primary GOT can be accessed in the most
effective way. If it is not possible, try to fill the last GOT in the
multi-GOT list, and finally create a new GOT if both attempts failed.
llvm-svn: 335140
microMIPS 64-bit is unsupported by LLVM starting from r335057. But such
code can be generated by GCC. Mark failed test cases as XFAIL while
decide to drop microMIPS 64-bit support from LLD too or use binary
inputs for the test.
llvm-svn: 335059
Summary: For --wrap foo --wrap foo, bfd/gold wrap the symbol only once but LLD would rotate it twice.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D48298
llvm-svn: 334991
This is a follow up requested during post commit review for
"[lld] r333880 - [ELF] - Also use DW_AT_linkage_name when gathering information about variables for error messages."
It removes checking of the input objects since it is really excessive.
llvm-svn: 334946
Summary:
R_X86_64_GOTOFF64: S + A - GOT
R_X86_64_GOTPC{32,64}: GOT + A - P (R_GOTONLY_PC_FROM_END)
R_X86_64_GOTOFF64 should use R_GOTREL_FROM_END so that in conjunction with
R_X86_64_GOTPC{32,64}, the `GOT` term is neutralized. This also matches
the handling of R_386_GOTOFF (S + A - GOT).
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D48095
llvm-svn: 334672
Summary:
Any invocation of `clang -fuse-ld=lld` that results in a link command
on a macOS host currently fails, because the Darwin lld driver does not
recognize the `-lto_library` option that Clang passes it. Fix the error
by having the Darwin driver ignore the option.
The Clang driver's macOS toolchain is written such that it will always
pass the `-lto_library` option to the linker invocation on a macOS host.
And although the DarwinLdDriver is written to ignore any unknown arguments,
because `-lto_library` begins with `-l`, the DarwinLdDriver interprets it
as a library search command, for a library named "to_library". When the
DarwinLdDriver is unable to find a library specified via `-l`, it exits
with a hard error. This causes any invocation of `clang -fuse-ld=lld`
that results in a link command on a macOS host to fail with an error.
To fix the issue, I considered two alternatives:
1. Modify the Clang Darwin toolchain to only pass `-lto_library` if lld
is *not* being used. lld doesn't support LTO on Darwin anyway, so it
can't use the option. However, I opted against this because, if and
when lld *does* support LTO on Darwin, I'll have to make another
commit to Clang in order to get it to pass the option to lld again.
2. Modify the Darwin lld driver to ignore the `-lto_library` option.
Just in case users may take this to mean LTO is supported, I also
added a warning. If and when lld supports LTO on Darwin, the same
commit that adds support for this option can remove the warning.
Option (2) seemed better to me, and is the rationale behind this commit.
Test Plan: check-lld
Reviewers: ruiu, smeenai, pcc
Reviewed By: smeenai
Subscribers: JDevlieghere, pcc, mehdi_amini, inglorion, steven_wu, llvm-commits
Differential Revision: https://reviews.llvm.org/D47994
llvm-svn: 334641
WebAssembly depends on attributes.h which includes attributes.inc.
Unless cmake explicitly specifies this dependency, the .inc file
is sometimes generated after the build tries to use it.
Patch by Stella Stamenova
llvm-svn: 334581
`lld-link foo.lib /wholearchive:foo.lib` should work the same way as
`lld-link /wholearchive:foo.lib foo.lib`. Previously, /wholearchive in
the former case was ignored.
Differential Revision: https://reviews.llvm.org/D47565
llvm-svn: 334552
When running with linker GC (`-opt:ref`), defined imported symbols that
are referenced but then dropped by GC end up with their `Location`
member being nullptr, which means `getChunk()` returns nullptr for them
and attempting to call `getChunk()->getOutputSection()` causes a crash
from the nullptr dereference. Check for `getChunk()` being nullptr and
bail out early to avoid the crash.
Differential Revision: https://reviews.llvm.org/D48092
llvm-svn: 334548
R_X86_64_GOTOFF64 is a relocation type to set to a distance betwween
a symbol and the beginning of the .got section. Previously, we always
created a dynamic relocation for the relocation type even though it
can be resolved at link-time.
Creating a dynamic relocation for R_X86_64_GOTOFF64 caused link failure
for some programs that do have a relocation of the type in a .text
section, as text relocations are prohibited in most configurations.
Differential Revision: https://reviews.llvm.org/D48058
llvm-svn: 334534
This simplifies some code which had StringRefs to begin with, and
makes other code more complicated which had const char* to begin
with.
In the end, I think this makes for a more idiomatic and platform
agnostic API. Not all platforms launch process with null terminated
c-string arrays for the environment pointer and argv, but the api
was designed that way because it allowed easy pass-through for
posix-based platforms. There's a little additional overhead now
since on posix based platforms we'll be takign StringRefs which
were constructed from null terminated strings and then copying
them to null terminate them again, but from a readability and
usability standpoint of the API user, I think this API signature
is strictly better.
llvm-svn: 334518
Summary:
Previously LLD would not add any dynamic relocations and write a module
index of 1 which is not correct for the shared library case.
This can happen when a thread-local global variable is marked as local with
a version script. With this change I am now able to link all of the FreeBSD
base system for MIPS64 with LLD.
Differential Revision: https://reviews.llvm.org/D48002
llvm-svn: 334483
Summary:
Error handling in liblldCore and the Darwin toolchain prints to an
output stream. A TODO in the project explained that a diagnostics
interface resembling Clang's should be added.
For now, the simple diagnostics interface defined in liblldCommon seems
like an improvement. It prints colors when they're available, uses locks
for thread-safety, and abstracts away the `"error: "` and newline
literal strings that litter the Darwin toolchain code.
To use the liblldCommon error handler, a link dependency is added to
the liblldDriver library.
Test Plan:
1. check-lld
2. Invoke `ld64.lld -r` in a terminal that supports color output.
Confirm that "ld64.lld: error: -arch not specified and could not be inferred"
is output, and that the "error:" is colored red!
Reviewers: ruiu, smeenai
Reviewed By: ruiu
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D47998
llvm-svn: 334466
Patch adds support for most of the dynamic thread pointer based relocations
for local-dynamic tls. The HIGH and HIGHA versions are missing becuase they
are not supported by the llvm integrated assembler yet.
llvm-svn: 334465
In glibc libc.so.6, the multiple versions of sys_errlist share the same Symbol instance. When sys_errlist is copy relocated, we would replace SharedSymbol with Defined in the first iteration of the following loop:
for (SharedSymbol *Sym : getSymbolsAt<ELFT>(SS))
Then in the second iteration, we think the symbol (which has been changed to Defined) is still SharedSymbol and screw up (the address ends up in the `Size` field).
llvm-svn: 334432
Almost all entries inside MIPS GOT are referenced by signed 16-bit
index. Zero entry lies approximately in the middle of the GOT. So the
total number of GOT entries cannot exceed ~16384 for 32-bit architecture
and ~8192 for 64-bit architecture. This limitation makes impossible to
link rather large application like for example LLVM+Clang. There are two
workaround for this problem. The first one is using the -mxgot
compiler's flag. It enables using a 32-bit index to access GOT entries.
But each access requires two assembly instructions two load GOT entry
index to a register. Another workaround is multi-GOT. This patch
implements it.
Here is a brief description of multi-GOT for detailed one see the
following link https://dmz-portal.mips.com/wiki/MIPS_Multi_GOT.
If the sum of local, global and tls entries is less than 64K only single
got is enough. Otherwise, multi-got is created. Series of primary and
multiple secondary GOTs have the following layout:
```
- Primary GOT
Header
Local entries
Global entries
Relocation only entries
TLS entries
- Secondary GOT
Local entries
Global entries
TLS entries
...
```
All GOT entries required by relocations from a single input file
entirely belong to either primary or one of secondary GOTs. To reference
GOT entries each GOT has its own _gp value points to the "middle" of the
GOT. In the code this value loaded to the register which is used for GOT
access.
MIPS 32 function's prologue:
```
lui v0,0x0
0: R_MIPS_HI16 _gp_disp
addiu v0,v0,0
4: R_MIPS_LO16 _gp_disp
```
MIPS 64 function's prologue:
```
lui at,0x0
14: R_MIPS_GPREL16 main
```
Dynamic linker does not know anything about secondary GOTs and cannot
use a regular MIPS mechanism for GOT entries initialization. So we have
to use an approach accepted by other architectures and create dynamic
relocations R_MIPS_REL32 to initialize global entries (and local in case
of PIC code) in secondary GOTs. But ironically MIPS dynamic linker
requires GOT entries and correspondingly ordered dynamic symbol table
entries to deal with dynamic relocations. To handle this problem
relocation-only section in the primary GOT contains entries for all
symbols referenced in global parts of secondary GOTs. Although the sum
of local and normal global entries of the primary got should be less
than 64K, the size of the primary got (including relocation-only entries
can be greater than 64K, because parts of the primary got that overflow
the 64K limit are used only by the dynamic linker at dynamic link-time
and not by 16-bit gp-relative addressing at run-time.
The patch affects common LLD code in the following places:
- Added new hidden -mips-got-size flag. This flag required to set low
maximum size of a single GOT to be able to test the implementation using
small test cases.
- Added InputFile argument to the getRelocTargetVA function. The same
symbol referenced by GOT relocation from different input file might be
allocated in different GOT. So result of relocation depends on the file.
- Added new ctor to the DynamicReloc class. This constructor records
settings of dynamic relocation which used to adjust address of 64kb page
lies inside a specific output section.
With the patch LLD is able to link all LLVM+Clang+LLD applications and
libraries for MIPS 32/64 targets.
Differential revision: https://reviews.llvm.org/D31528
llvm-svn: 334390
This causes all symbols to be exported in the final wasm binary
even if they were not compiled with default visibility.
This feature is useful for the emscripten toolchain that has a
corresponding EXPORT_ALL feature which allows the JS code to
interact with all C function.
Differential Revision: https://reviews.llvm.org/D47806
llvm-svn: 334157
Summary:
When reporting an unsupported relocation type, let's also report the
file we encountered it in to aid diagnosis.
Reviewers: ruiu, rnk
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45911
llvm-svn: 334154
The original computation for shared object symbol alignment is wrong when
st_value equals 0. It is very unusual for dso symbols to have st_value equal 0.
But when it happens, it causes obscure run time bugs.
Differential Revision: https://reviews.llvm.org/D47602
llvm-svn: 334135
If building lld without x86 support, tests that require that support should
be treated as unsupported, not errors.
Tested using:
1. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64;X86'
make check-lld
=>
Expected Passes : 1406
Unsupported Tests : 287
2. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64'
make check-lld
=>
Expected Passes : 410
Unsupported Tests : 1283
Patch by Joel Jones
Differential Revision: https://reviews.llvm.org/D47748
llvm-svn: 334095
Previously, "-m is missing" error message is shown if you pass a
nonexistent file or don't pass any file at all to lld, as shown below:
$ ld.lld nonexistent.o
ld.lld: error: cannot open nonexistent.o: No such file or directory
ld.lld: error: target emulation unknown: -m or at least one .o file required
This patch eliminates the second error message because it's not related
and even inaccurate (you passed a .o file though it didn't exist).
llvm-svn: 334024
Currently, when LLD do a lookup for variables location, it uses DW_AT_name attribute.
That is not always enough.
Imagine code:
namespace A {
int bar = 0;
}
namespace Z {
int bar = 1;
}
int hoho;
In this case there are 3 variables and their debug attributes are following:
A::bar has: DW_AT_name [DW_FORM_string] ("bar") DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x00000006] = "_ZN1A3barE")
Z::bar has: DW_AT_name [DW_FORM_string] ("bar") DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0000003f] = "_ZN1Z3barE")
hoho has: DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000004a] = "hoho") and has NO DW_AT_linkage_name attribute. Because it would be
the same as DW_AT_name and DWARF producers avoids emiting excessive data.
Hence LLD should also use DW_AT_linkage_name when it is available.
(currently, LLD fails to report location correctly because thinks that A::bar and Z::bar are the same things)
Differential revision: https://reviews.llvm.org/D47373
llvm-svn: 333880
Clang passes --plugin /path/to/LLVMgold.so to the linker when -flto is
passed. After r333607 we only ignore --plugin as a joined argument,
which means that the following argument (/path/to/LLVMgold.so) is
interpreted as an input file. This means that either every LTO'd
program ends up being linked with the gold plugin or we error out
if the plugin does not exist. The fix is to use Eq to ignore both
--plugin=foo and --plugin foo as before.
Differential Revision: https://reviews.llvm.org/D47657
llvm-svn: 333793
Since aliases don't actually need name, I removed it from Options.td
to keep the definitions concise.
Before:
-( Ignored for compatibility with GNU unless you pass --warn-backrefs
-) Ignored for compatibility with GNU unless you pass --warn-backrefs
--allow-multiple-definition Allow multiple definitions
--apply-dynamic-relocs Apply dynamic relocations to place
--as-needed Only set DT_NEEDED for shared libraries if used
--auxiliary=<value> Set DT_AUXILIARY field to the specified name
--Bdynamic Link against shared libraries
--Bshareable Build a shared object
...
After:
-( Alias for --start-group
-) Alias for --end-group
--allow-multiple-definition Allow multiple definitions
--apply-dynamic-relocs Apply dynamic relocations to place
--as-needed Only set DT_NEEDED for shared libraries if used
--auxiliary=<value> Set DT_AUXILIARY field to the specified name
--Bdynamic Link against shared libraries (default)
--Bshareable Alias for --shared
...
Differential Revision: https://reviews.llvm.org/D47588
llvm-svn: 333694
Summary:
After r333596, rpath-link no longer consumes the following argument, and
the path argument left by it confuses LLD.
Reviewers: espindola, ruiu
Reviewed By: ruiu
Subscribers: ruiu, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D47591
llvm-svn: 333686
Add support for the R_PPC64_GOT_TLSLD16 relocations used to build the address of
the tls_index struct used in local-dynamic tls.
Differential Revision: https://reviews.llvm.org/D47538
llvm-svn: 333681
getRelocTargetVA for R_TLSGD and R_TLSLD RelExprs calculate an offset from the
end of the got, so adjust the names to reflect this.
Differential Revision: https://reviews.llvm.org/D47379
llvm-svn: 333674
--push-state implemented in this patch saves the states of --as-needed,
--whole-archive and --static. It saves less number of flags than GNU linkers.
Since even GNU linkers save different flags, no one seems to care about the
details. In this patch, I tried to save the minimal number of flags to not
complicate the implementation and the siutation.
I'm not personally happy about adding the --{push,pop}-state flags though.
That options seem too hacky to me. However, gcc started using the options
since GCC 8 when GNU ld is available at the build time. Therefore, lld
is no longer a drop-in replacmenet for GNU linker for that machine
without supporting the flags.
Fixes https://bugs.llvm.org/show_bug.cgi?id=34567
Differential Revision: https://reviews.llvm.org/D47542
llvm-svn: 333646
Previously, we printed out two lines of help messages for `--foo bar`
and `--foo=bar` like this:
--soname=<value> Set DT_SONAME
--soname <value> Set DT_SONAME
--sort-section=<value> Specifies sections sorting rule when linkerscript is used
--sort-section <value> Specifies sections sorting rule when linkerscript is used
This change eliminates duplicate lines that doesn't contain `=` for such
options like this.
--soname=<value> Set DT_SONAME
--sort-section=<value> Specifies sections sorting rule when linkerscript is used
Differential Revision: https://reviews.llvm.org/D47558
llvm-svn: 333596
This should be correctly implied by the linker.
This also makes the tests slightly easier to maintain and compare
with the equivalent tests under for other platforms.
Differential Revision: https://reviews.llvm.org/D47513
llvm-svn: 333567
The comment only made sense a long time ago, when --thinlto-jobs was
tied with --lto-partitions. That was changed in r283817, but the test
wasn't updated at the same time. This patch does so.
llvm-svn: 333480
Peter Collingbourne suggested moving the switch to the top of the
function, so that all the code that cares about the output section for a
symbol is in the same place.
Differential Revision: https://reviews.llvm.org/D47497
llvm-svn: 333472
Rather than using a loop to compare symbol RVAs to the starting RVAs of
sections to determine which section a symbol belongs to, just get the
output section of a symbol directly via its chunk, and bail if the
symbol doesn't have an output section, which avoids having to hardcode
logic for handling dead symbols, CodeView symbols, etc. This was
suggested by Reid Kleckner; thank you.
This also fixes writing out symbol tables in the presence of RVA table
input sections (e.g. .sxdata and .gfids). Such sections aren't written
to the output file directly, so their RVA is 0, and the loop would thus
fail to find an output section for them, resulting in a segfault. Extend
some existing tests to cover this case.
Fixes PR37584.
Differential Revision: https://reviews.llvm.org/D47391
llvm-svn: 333450
Adds handling of all the relocation types for general-dynamic thread local
storage.
Differential Revision: https://reviews.llvm.org/D47325
llvm-svn: 333420
Fangrui Song