Summary:
This is a common error, and because many people don't know what the key
function is, it is sometimes very confusing.
The doc was originally written by Brooks Moses and slightly edited by me.
Reviewers: MaskRay, espindola
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55968
llvm-svn: 349941
This is an reland of rL343155 which got reverted because
of a sphinx failure on the buildbot.
Differential Revision: https://reviews.llvm.org/D54982
llvm-svn: 347830
This is https://bugs.llvm.org//show_bug.cgi?id=38978
Spec says that:
"Objects may be built with the -z nodefaultlib option to
suppress any search of the default locations at runtime.
Use of this option implies that all the dependencies of an
object can be located using its runpaths.
Without this option, which is the most common case, no
matter how you augment the runtime linker's library
search path, its last element is always /usr/lib for 32-bit
objects and /usr/lib/64 for 64-bit objects."
The patch implements this option.
Differential revision: https://reviews.llvm.org/D54577
llvm-svn: 347647
Summary:
This patch adds a new flag, --warn-ifunc-textrel, to work around a glibc bug. When a code with ifunc symbols is used to produce an object file with text relocations, lld always succeeds. However, if that object file is linked using an old version of glibc, the resultant binary just crashes with segmentation fault when it is run (The bug is going to be corrected as of glibc 2.19).
Since there is no way to tell beforehand what library the object file will be linked against in the future, there does not seem to be a fool-proof way for lld to give an error only in cases where the binary will crash. So, with this change (dated 2018-09-25), lld starts to give a warning, contingent on a new command line flag that does not have a gnu counter part. The default value for --warn-ifunc-textrel is false, so lld behaviour will not change unless the user explicitly asks lld to give a warning. Users that link with a glibc library with version 2.19 or newer, or does not use ifunc symbols, or does not generate object files with text relocations do not need to take any action. Other users may consider to start passing warn-ifunc-textrel to lld to get early warnings.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: grimar, MaskRay, markj, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52430
llvm-svn: 343628
-z interpose sets the DF_1_INTERPOSE flag, marking the object as an
interposer.
Via FreeBSD PR 230604, linking Valgrind with lld failed.
Differential Revision: https://reviews.llvm.org/D52094
llvm-svn: 342239
--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
Also remove the space between --lto-O and value, as the option with a
space is not accepted at present.
Leave --opt-remarks-filename as it does not currently accept the = form.
llvm.org/pr36563
llvm-svn: 326536
The argument is section=address, not just address.
(For compatibility with GNU linkers we need to, but do not yet, accept
--section-start=section=address.)
llvm-svn: 326463
We intend to maintain compatibility with GNU ld, and in the GNU world
long options are conventionally specified as --long-option=value. For
whatever reason GNU ld.bfd accepts both --long-option value and
--long-option=value, but documents the former. Follow suit.
Some lld long options do not accept the = form; this is probably a bug
to be fixed (along with a man page update).
Reported by Ingo Schwarze, for --entry.
llvm-svn: 326459
Initial ld.lld.1 man page commit in r324512 crossed paths with r324502
which added --build-id=fast, allowing --build-id to be documented as a
synonym for --build-id=fast. Catch up with that change in the man page.
Differential Revision: https://reviews.llvm.org/D43039
llvm-svn: 324528
One of the FreeBSD requirements for enabling lld as the system linker is
that it has a man page. Other FreeBSD developers and I created one using
lld's --help output as a starting point. This is an expanded and
improved version of that.
This man page would benefit from additional content, but it provides
basic user-facing coverage of lld's options and serves as a good
starting point.
Differential Revision: https://reviews.llvm.org/D42963
llvm-svn: 324512
This linker backend is still a work in progress but is
enough to link simple programs including linking against
library archives.
Differential Revision: https://reviews.llvm.org/D34851
llvm-svn: 318539
SymbolBody and Symbol were separated classes due to a historical reason.
Symbol used to be a pointer to a SymbolBody, and the relationship
between Symbol and SymbolBody was n:1.
r2681780 changed that. Since that patch, SymbolBody and Symbol are
allocated next to each other to improve memory locality, and they have
1:1 relationship now. So, the separation of Symbol and SymbolBody no
longer makes sense.
This patch merges them into one class. In order to avoid updating too
many places, I chose SymbolBody as a unified name. I'll rename it Symbol
in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D39406
llvm-svn: 317006
New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.
Differential Revision: https://reviews.llvm.org/D37645
llvm-svn: 314719
Martin Storsjo