Don't create a dummy __tls_get_addr.
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.
Pull in r320390 from upstream lld trunk (by Rafael Espindola):
Create reserved symbols early so they can be versioned.
This fixes pr35570.
We were creating these symbols after parsing version scripts, so they
could not be versioned.
We cannot move the version script parsing later because we need it for
lto.
One option is to move both addReservedSymbols and
createSyntheticSections earlier. The disadvantage is that some
sections created by createSyntheticSections replace other input
sections. For example, gdb index replaces .debug_gnu_pubnames, so it
wants to run after gc sections so that it can set S->Live to false.
What this patch does instead is to move just the ElfHeader creation
early.
Pull in r320412 from upstream lld trunk (by Rafael Espindola):
Handle symbols pointing to output sections.
Now that gc sections runs after linker defined symbols are added it
can see symbols that point to an OutputSection.
Should fix a bot failure.
Pull in r320431 from upstream lld trunk (by Peter Collingbourne):
ELF: Do not follow relocation edges to output sections during GC.
This fixes an assertion error introduced by r320390.
Differential Revision: https://reviews.llvm.org/D41095
Together these fix handling of reserved symbols, in particular _end,
which is needed to make brk(2) and sbrk(2) work correctly. This
unbreaks the emacs ports on amd64, and also appears to unbreak most of
world on i386.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13466
Previously, lld exited with an error status if the only option given to
the command was -v. GNU linkers gracefully exit in that case. This patch
makes lld behave like GNU.
Note that even with this patch, lld's -v and --version options behave
slightly differently than GNU linkers' counterparts. For example,
if you run ld.bfd -v -v, the version string is printed out twice.
But that is an edge case that I don't think we need to take care of.
Fixes https://bugs.llvm.org/show_bug.cgi?id=31582
Obtained from: LLVM r319717
MFC after: 1 week
GNU libtool checks the output from invoking the linker with --version
and --help, in order to determine the linker "flavour" and the command-
ine arguments to use for various link operations (e.g. generating shared
libraries). To detect GNU ld it looks for the strings "GNU" and
"supported targets:.*elf". Since LLD is compatible with GNU ld we
include those same strings to fool libtool.
Quoting from a comment in the change:
This is somewhat ugly hack, but in reality, we had no choice other
than doing this. Considering the very long release cycle of Libtool,
it is not easy to improve it to recognize LLD as a GNU compatible
linker in a timely manner. Even if we can make it, there are still a
lot of "configure" scripts out there that are generated by old
version of Libtool. We cannot convince every software developer to
migrate to the latest version and re-generate scripts. So we have
this hack.
Upstream LLVM revisions r298532, r298568, r298591
Obtained from: LLVM
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
