There seems to be no reason to collect this list of symbols.
Also fix a bug where --exclude-libs would apply to all symbols that
appear in an archive's symbol table, even if the relevant archive
member was not added to the link.
Differential Revision: https://reviews.llvm.org/D43369
llvm-svn: 325380
Newer versions of the gnu assembler produce a X86_64_PLT32 for
calls. There is a change under review in llvm to do the same, so update
the tests to not depend on it.
We can still produce a R_X86_64_PC32 with ".long foo - .".
llvm-svn: 325379
This bug effected undefined symbols that were resolved by
existing defined symbols. We were skipping the signature
check in this case.
Differential Revision: https://reviews.llvm.org/D43399
llvm-svn: 325376
Reviewed by: rafael
Differential Revision: https://reviews.llvm.org/D43336
There is some discussion as to the exact behaviour of combining ICF and
--symbol-ordering-file, but it seems beneficial to warn when attempting
to order the removed symbol regardless of the preferred approach.
llvm-svn: 325333
Summary:
This follows up on r321889 where writing of Elf_Rel addends was partially
moved to RelocationBaseSection. This patch ensures that the addends are
always written to the output section when a input section uses RELA but the
output is REL.
Differential Revision: https://reviews.llvm.org/D42843
llvm-svn: 325328
Previously, we accidentally dropped STB_WEAK bit from an undefined symbol
if there is a lazy object symbol with the same name. That caused a
compatibility issue with GNU gold.
llvm-svn: 325316
Even though it doesn't make sense, there seems to be multiple programs
in the wild that create PC-relative relocations in non-ALLOC sections.
I believe this is caused by the negligence of GNU linkers to not report
any errors for such relocations.
Currently, lld emits warnings against such relocations and exits.
So, you cannot link any program that contains wrong relocations until
you fix an issue in a program that generates wrong ELF files. It's often
impractical to fix a program because it's not always easy.
This patch relaxes the error checking and emit a warning instead.
Differential Revision: https://reviews.llvm.org/D43351
llvm-svn: 325307
When we are emitting a relocatable output, we should keep the original
symbol name including "@" part. Previously, we drop that part unconditionally
which resulted in dropping versions from symbols.
Differential Revision: https://reviews.llvm.org/D43307
llvm-svn: 325204
This patch addresses a minor compatibility issue with GNU linkers.
Previously, --export-dynamic-symbol is completely ignored if you
pass --export-dynamic together.
Differential Revision: https://reviews.llvm.org/D43266
llvm-svn: 325152
There are a number of different situations when symbols are requested
to be ordered in the --symbol-ordering-file that cannot be ordered for
some reason. To assist with identifying these symbols, and either
tidying up the order file, or the inputs, a number of warnings have
been added. As some users may find these warnings unhelpful, due to how
they use the symbol ordering file, a switch has also been added to
disable these warnings.
The cases where we now warn are:
* Entries in the order file that don't correspond to any symbol in the input
* Undefined symbols
* Absolute symbols
* Symbols imported from shared objects
* Symbols that are discarded, due to e.g. --gc-sections or /DISCARD/ linker script sections
* Multiple of the same entry in the order file
Reviewed by: rafael, ruiu
Differential Revision: https://reviews.llvm.org/D42475
llvm-svn: 325125
Summary:
This protects calls to longjmp from transferring control to arbitrary
program points. Instead, longjmp calls are limited to the set of
registered setjmp return addresses.
This also implements /guard:nolongjmp to allow users to link in object
files that call setjmp that weren't compiled with /guard:cf. In this
case, the linker will approximate the set of address taken functions,
but it will leave longjmp unprotected.
I used the following program to test, compiling it with different -guard
flags:
$ cl -c t.c -guard:cf
$ lld-link t.obj -guard:cf
#include <setjmp.h>
#include <stdio.h>
jmp_buf buf;
void g() {
printf("before longjmp\n");
fflush(stdout);
longjmp(buf, 1);
}
void f() {
if (setjmp(buf)) {
printf("setjmp returned non-zero\n");
return;
}
g();
}
int main() {
f();
printf("hello world\n");
}
In particular, the program aborts when the code is compiled *without*
-guard:cf and linked with -guard:cf. That indicates that longjmps are
protected.
Reviewers: ruiu, inglorion, amccarth
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43217
llvm-svn: 325047
When decompressing a compressed debug section, we drop SHF_COMPRESSED
flag but we didn't drop "z" in ".zdebug" section name. This patch does
that for consistency.
This change also fixes the issue that .zdebug_gnu_pubnames are not
dropped when we are creating a .gdb_index section.
llvm-svn: 324949
GNU gold doesn't print out ICF sections for -verbose. It only shows
them for -print-icf-sections. We printed out them for -verbose because
we didn't have -print-icf-sections. Now that we have the option, there's
no reason to print out for -verbose.
Differential Revision: https://reviews.llvm.org/D43100
llvm-svn: 324755
This is for compatiblity with GNU gold. GNU gold tries to resolve
symbols specified by --export-dynamic-symbol. So, if a symbol specified
by --export-dynamic-symbol is in an archive file, lld's result is
currently different from gold's.
Interestingly, that behavior is different for --dynamic-list.
I added a new test to ensure that.
Differential Revision: https://reviews.llvm.org/D43103
llvm-svn: 324752
When you omit an argument, most options fall back to their defaults.
For example, --color-diagnostics is a synonym for --color-diagnostics=auto.
We don't have a way to specify the default choice for --build-id, so we
can't describe --build-id (without an argument) in that way.
This patch adds "fast" for the default build-id choice.
Differential Revision: https://reviews.llvm.org/D43032
llvm-svn: 324502
MIPS BFD linker puts _gp_disp symbol into DSO files and assigns zero
version definition index to it. This value means 'unversioned local
symbol' while _gp_disp is a section global symbol. We have to handle
this bug in the LLD because BFD linker is used for building MIPS
toolchain libraries.
Differential revision: https://reviews.llvm.org/D42486
llvm-svn: 324467
This is PR35740 which now crashes
because we remove unused synthetic sections incorrectly.
We can keep input section description and corresponding output
section live even if it must be empty and dead.
This results in a crash because SHF_LINK_ORDER handling code
tries to access first section which is nullptr in this case.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D42681
llvm-svn: 324463
Previously --defsym=foo2=etext+2 would produce incorrect value
for foo2 because expressions did not work correctly with
reserved symbols, section offset was calculated wrong for them.
Fixes PR35744.
Differential revision: https://reviews.llvm.org/D42911
llvm-svn: 324461
Previously we ignored -plugin-opt=mcpu=<xxx>
and the only way to set CPU string was to pass
-mllvm -mcpu=<xxx>
Though clang may pass it with use of plugin options:
-plugin-opt=mcpu=x86-64
Since we are trying to be compatible in command line
with gold plugin, seems we should support it too.
Differential revision: https://reviews.llvm.org/D42956
llvm-svn: 324459
In D42733 we supported different LTO command line
options, including -debugger-tune=<value>.
Initially debugger-tune support was needed to fix PR36035.
Patch adds testcase for this option to check we
don't simply ignore it.
Differential revision: https://reviews.llvm.org/D42961
llvm-svn: 324457
This is similar to _end (See https://linux.die.net/man/3/edata for more)
but using our own unique name since our use cases will most likely be
different and we want to keep our options open WRT to memory layout.
This change will allow is to remove the DataSize from the linking
metadata section which is currently being used by emscripten to derive
the end of the data.
Differential Revision: https://reviews.llvm.org/D42867
llvm-svn: 324443
objects, it confuses codegen into generating pc-rel relocations for those
symbols, which leads to linker errors.
Differential Revision: https://reviews.llvm.org/D42977
llvm-svn: 324435
In lld this was the only use of Config->Static where it meant anything
else other than "use .a instead of .so".
If a program turns out to not use any dynamic libraries, we should
produce the same result with and without -static.
llvm-svn: 324421
With fix:
Keep logic that ignores -plugin-opt=mcpu=x86-64 -plugin-opt=thinlto,
add checks for those to testcases.
Original commit message:
[ELF] - Use InitTargetOptionsFromCodeGenFlags/ParseCommandLineOptions for parsing LTO options.
gold plugin uses InitTargetOptionsFromCodeGenFlags +
ParseCommandLineOptions for parsing LTO options.
Patch do the same change for LLD.
Such change helps to avoid parsing/whitelisting LTO
plugin options again on linker side, what can help LLD
to automatically support new -plugin-opt=xxx options
passed.
Differential revision: https://reviews.llvm.org/D42733
llvm-svn: 324340
gold plugin uses InitTargetOptionsFromCodeGenFlags +
ParseCommandLineOptions for parsing LTO options.
Patch do the same change for LLD.
Such change helps to avoid parsing/whitelisting LTO
plugin options again on linker side, what can help LLD
to automatically support new -plugin-opt=xxx options
passed.
Differential revision: https://reviews.llvm.org/D42733
llvm-svn: 324322
Summary:
This patch adds some initial support for Windows control flow guard. At
the end of the day, the linker needs to synthesize a table of RVAs very
similar to the structured exception handler table (/safeseh).
Both /safeseh and /guard:cf take sections of symbol table indices
(.sxdata and .gfids$y) and turn them into RVA tables referenced by the
load config struct in the CRT through special symbols.
Reviewers: ruiu, amccarth
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42592
llvm-svn: 324306
When using Elf_Rela every tool should use the addend in the
relocation.
We have --apply-dynamic-relocs to work around bugs in tools that don't
do that.
The default value of --apply-dynamic-relocs should be false to make
sure these bugs are more easily found in the future.
llvm-svn: 324264
When resolving dynamic RELA relocations the addend is taken from the
relocation and not the place being relocated. Accordingly lld does not
write the addend field to the place like it would for a REL relocation.
Unfortunately there is some system software, in particlar dynamic loaders
such as Bionic's linker64 that use the value of the place prior to
relocation to find the offset that they have been loaded at. Both gold
and bfd control this behavior with the --[no-]apply-dynamic-relocs option.
This change implements the option and defaults it to true for compatibility
with gold and bfd.
Differential Revision: https://reviews.llvm.org/D42797
llvm-svn: 324221
We did not report valid filename for duplicate symbol error when
symbol came from binary input file.
Patch fixes it.
Differential revision: https://reviews.llvm.org/D42635
llvm-svn: 324217
Initially LLD generates Elf_Rel relocations for O32 ABI and Elf_Rela
relocations for N32 / N64 ABIs. In other words, format of input and
output relocations was always the same. Now LLD generates all output
relocations using Elf_Rel format only. It conforms to ABIs requirement.
The patch suggested by Alexander Richardson.
llvm-svn: 324064
Peter Collingbourne