This is a follow-up patch to r273218. GNU ld accepts both "--" and "-"
for all multi-letter options except "-o". This patch makes lld compatible
with that behavior.
llvm-svn: 273256
GNU ld's manual page says that all options whose names are
multiple letters, except those who start with "o", can start
either with one or two dashes.
llvm-svn: 273218
We would previously accept `--threads=4`, but this option just turns on
threading and does not specify a number of threads.
I ran into this by accident because I was passing `--threads=<n>` but
the number didn't seem to affect anything.
llvm-svn: 270963
--reproduce dumps the object files in a directory chosen
(preserving the file system layout) and the linker invocation
so that people can create an archive and upload for debugging.
Differential Revision: http://reviews.llvm.org/D19494
llvm-svn: 267497
This patch is to remove -lto-no-discard-value-names flag and
instead to use -save-temps as we discussed in the post-commit
review thread for r267020.
Differential Revision: http://reviews.llvm.org/D19437
llvm-svn: 267230
This patch only implements support for version scripts of the form:
{ [ global: symbol1; symbol2; [...]; symbolN; ] local: *; };
No wildcards are supported, other than for the local entry. Symbol versioning
is also not supported.
It works by introducing a new Symbol flag which tracks whether a symbol
appears in the global section of a version script.
This patch also simplifies the logic in SymbolBody::isPreemptible(), and
teaches it to handle the case where symbols with default visibility in DSOs
do not appear in the dynamic symbol table because of a version script.
Fixes PR27482.
Differential Revision: http://reviews.llvm.org/D19430
llvm-svn: 267208
GNU ld and gold only support the discard-all and discard-locals with two dashes.
Retain the compatibility with the one dash spelling, but also accept the two
dashed form.
llvm-svn: 267032
`--add-needed` and `--no-add-needed` have been deprecated due to the similarity
of their spelling to `--as-needed` and `--no-as-needed`. They have been renamed
to `--copy-dt-needed-entries` and `--no-copy-dt-needed-entries`.
llvm-svn: 267031
Rafael reported on the mailing list that this reduces peak memory
usage while linking llvm-as by 15%. It makes sense to make it
the default, and introduce an inverse knob -lto-no-discard-value-names
for those who want to restore the old behavior.
llvm-svn: 267020
Parallelism level can be chosen using the new --lto-jobs=K option
where K is the number of threads used for CodeGen. It currently
defaults to 1.
llvm-svn: 266484
This patch implements the --dynamic-list option, which adds a list of
global symbol that either should not be bounded by default definition
when creating shared libraries, or add in dynamic symbol table in the
case of creating executables.
The patch modifies the ScriptParserBase class to use a list of Token
instead of StringRef, which contains information if the token is a
quoted or unquoted strings. It is used to use a faster search for
exact match symbol name.
The input file follow a similar format of linker script with some
simplifications (it does not have scope or node names). It leads
to a simplified parser define in DynamicList.{cpp,h}.
Different from ld/gold neither glob pattern nor mangled names
(extern 'C++') are currently supported.
llvm-svn: 266227
Previously, we supported only one hash function, FNV-1, so
BuildIdSection directly handled hash computation. In this patch,
I made BuildIdSection an abstract class and defined two subclasses,
BuildIdFnv1 and BuildIdMd5.
llvm-svn: 265737
start-lib and end-lib are options to link object files in the same
semantics as archive files. If an object is in start-lib and end-lib,
the object is linked only when the file is needed to resolve
undefined symbols. That means, if an object is in start-lib and end-lib,
it behaves as if it were in an archive file.
In this patch, I introduced a new notion, LazyObjectFile. That is
analogous to Archive file type, but that works for a single object
file instead of for an archive file.
http://reviews.llvm.org/D18814
llvm-svn: 265710
Stack is not executable by default in LLD-built executables unless
you pass -z execstack option. So --warn-execstack option does not make
sense to us.
llvm-svn: 265619
So, there are some cases when the IR Linker produces a broken
module (which doesn't pass the verifier) and we end up asserting
inside the verifier. I think it's always a bug producing a module
which does not pass the verifier but there are some cases in which
people can live with the broken module (e.g. if only DebugInfo
metadata are broken). The gold plugin has something similar.
This commit is motivated by a situation I found in the
wild. It seems that somebody else discovered it independently
and reported in PR24923.
llvm-svn: 265258
GNU ld seems to write a PT_INTERP header into executables containing a
default (read: bogus) value if --dynamic-linker flag is not provided.
LLD is different in the sense that it omits it unless --dynamic-linker
is provided, which seems fair.
Binutils 2.26 added a new flag, --no-dynamic-linker, that can be used to
generate binaries without PT_INTERP. Let's go ahead and also add this
flag to LLD, so that we can invoke the linker in a portable way.
Reviewed by: ruiu
Differential Revision: http://reviews.llvm.org/D18723
llvm-svn: 265246
Just ignore the -rpath-link command line
option in the same way like gold do.
Behavior of lld/gold differs from gnu ld here.
GNU ld tries to resolve undefined symbols in all
shared object files at link time.
Differential revision: http://reviews.llvm.org/D18269
llvm-svn: 263876
This is required to get 'clang -flto' to work transparently
with lld. Please refer to the short comment in the code
for a more detailed explanation.
llvm-svn: 263862
-pie
--pic-executable
Create a position independent executable. This is currently only
supported on ELF platforms. Position independent executables are
similar to shared libraries in that they are relocated by the
dynamic linker to the virtual address the OS chooses for them
(which can vary between invocations). Like normal dynamically
linked executables they can be executed and symbols defined in the
executable cannot be overridden by shared libraries.
Differential revision: http://reviews.llvm.org/D18183
llvm-svn: 263693
-warn-common
Warn when a common symbol is combined with another common symbol
or with a symbol definition. Unix linkers allow this somewhat
sloppy practice, but linkers on some other operating systems do
not. This option allows you to find potential problems from
combining global symbols.
Differential revision: http://reviews.llvm.org/D17998
llvm-svn: 263413
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
This patch adds --thread option and use parallel_for_each to write
sections in regular OutputSections.
This is the first patch to use more than one threads.
Note that --thread is off by default because it is experimental.
At this moment I still want to focus on single thread performance
because multi-threading is not a magic wand to fix performance
problems after all. It is generally very hard to make a slow program
faster by threads. Therefore, I want to make the linker as efficient
as possible first and then look for opportunity to make it even faster
using more than one core.
Here are some numbers to link programs with and without --threads
and using GNU gold. Numbers are in seconds.
Clang
w/o --threads 0.697
w --threads 0.528
gold 1.643
Scylla
w/o --threads 5.032
w --threads 4.935
gold 6.791
GNU gold
w/o --threads 0.550
w --threads 0.551
gold 0.737
I limited the number of cores these processes can use to 4 using
perf command, so although my machine has 20 physical cores, the
performance gain I observed should be reproducible with a machine
which is not as beefy as mine.
llvm-svn: 263190
Summary:
This is useful for debugging issues with LTO.
The option follows the analogous option in ld64 and the gold plugin (per
Rafael's suggestion).
For starters, this only dumps the combined bitcode file.
In a future patch I will add dumping for the .o file.
The naming of the output follows ld64's convention which is slightly more
consistent IMO (consistent `.lto.<extension>` for all the files).
Reviewers: rafael, ruiu
Subscribers: joker.eph, Bigcheese, llvm-commits
Differential Revision: http://reviews.llvm.org/D18006
llvm-svn: 263055
It was causing errors like
/lib/libc.so.6 is incompatible with elf_x86_64
when linking on Fedora.
Every system has different default paths. It seems better to just trust
the driver to pass the correct -L options.
This reverts commit 262910.
llvm-svn: 262941
Rui Ueyama