t is possible to create new version of symbol instead of depricated one
using combination of version script and asm commands. For example:
__asm__(".symver b_1,b@LIBSAMPLE_1.0");
int b_1() { return 10; }
__asm__(".symver b_2,b@@LIBSAMPLE_2.0");
int b_2() { return 20; }
This code makes b_2() to be default implementation for b().
b_1() is used for compatibility with binaries compiled against
library of older version LIBSAMPLE_1.0.
This patch implements support for above functionality in lld.
Differential revision: http://reviews.llvm.org/D21681
llvm-svn: 274002
Option checks for cases where a version script explicitly lists
a symbol, but the symbol is not defined and errors out such
cases if any.
Differential revision: http://reviews.llvm.org/D21745
llvm-svn: 273998
Patch by Shridhar Joshi.
This option provides names of all the link time modules which define and
reference symbols requested by user. This helps to speed up application
development by detecting references causing undefined symbols.
It also helps in detecting symbols being resolved to wrong (unintended)
definitions in case of applications containing multiple definitions for
same symbols with different types, bindings.
Implements PR28226.
llvm-svn: 273536
For next version script:
VER1{
global:
a;
};
VER2{
global:
a;
};
gold would produce warning like:
"warning: using 'VER1' as version for 'a' which is also named in version 'VER2' in script."
Documentation also says we do not want this duplications (https://people.freebsd.org/~deischen/symver/library_versioning.txt):
"Note that you do not want to duplicate symbols in the map file. The .symver directives are all that is required to add compatibility
symbols into old versions."
This patch restricts such mixing and makes lld to produce error in this case.
Differential revision: http://reviews.llvm.org/D21555
llvm-svn: 273396
With fix:
-soname flag was not set in testcase. Hash calculated for base def was different on local
and bot machines because filename fos used for calculating.
Initial commit message:
Patch implements basic support of versioned symbols.
There is no wildcards patterns matching except local: *;
There is no support for hierarchies.
There is no support for symbols overrides (@ vs @@ not handled).
This patch allows programs that using simple scripts to link and run.
Differential revision: http://reviews.llvm.org/D21018
llvm-svn: 273152
Patch implements basic support of versioned symbols.
There is no wildcards patterns matching except local: *;
There is no support for hierarchies.
There is no support for symbols overrides (@ vs @@ not handled).
This patch allows programs that using simple scripts to link and run.
Differential revision: http://reviews.llvm.org/D21018
llvm-svn: 273143
Doing that in an anonymous version is a bit silly, but this opens the
way for supporting it in general.
Since we don't support actual versions, for now we just disable the
version script if we detect that it is missing a local.
llvm-svn: 273000
This should never happen with correct programs, but it is trivial
write a testcase where lld would crash or report duplicated
symbols. We now behave like when an archive is used and include the
file only once.
llvm-svn: 272724
We can now use this to decide whether to emit a verneed during the final
pass over the symbols. We were previously wrongly creating a verneed entry
in the case where all references to a DSO's symbols were weak.
In a future change we may also want to use the used bit to control whether
shared symbols are preemptible and appear in the dynsym. This seems a little
tricky to do at the moment because isNeeded() is templated.
The only other functional change here is that we emit a DT_NEEDED for DSOs
whose symbols are all preempted by objects that appear later in the link. But
that doesn't seem too important to me.
Differential Revision: http://reviews.llvm.org/D21171
llvm-svn: 272282
Introduce a special symbol type to indicate that we have not yet seen a type
for the symbol, so we should not report TLS mismatches for that symbol.
Differential Revision: http://reviews.llvm.org/D19836
llvm-svn: 268411
Weak undefined symbols resolve to the image base. This is a little strange,
but it allows us to link function calls to such symbols. Normally such a
call will be guarded with a comparison, which will load a zero from the GOT.
There's one example of such a function call in crti.o in Linux's CRT.
As part of this change, I also needed to make the synthetic start and end
symbols image base relative in the case where their sections were empty,
so that PC-relative references to those symbols would continue to work.
Differential Revision: http://reviews.llvm.org/D19844
llvm-svn: 268350
This patch increases the size of Undefined by the size of a pointer,
but it wouldn't actually increase the size of memory that LLD uses
because we are not allocating the exact size but the size of the
largest SymbolBody.
llvm-svn: 268310
This patch implements a new design for the symbol table that stores
SymbolBodies within a memory region of the Symbol object. Symbols are mutated
by constructing SymbolBodies in place over existing SymbolBodies, rather
than by mutating pointers. As mentioned in the initial proposal [1], this
memory layout helps reduce the cache miss rate by improving memory locality.
Performance numbers:
old(s) new(s)
Without debug info:
chrome 7.178 6.432 (-11.5%)
LLVMgold.so 0.505 0.502 (-0.5%)
clang 0.954 0.827 (-15.4%)
llvm-as 0.052 0.045 (-15.5%)
With debug info:
scylla 5.695 5.613 (-1.5%)
clang 14.396 14.143 (-1.8%)
Performance counter results show that the fewer required indirections is
indeed the cause of the improved performance. For example, when linking
chrome, stalled cycles decreases from 14,556,444,002 to 12,959,238,310, and
instructions per cycle increases from 0.78 to 0.83. We are also executing
many fewer instructions (15,516,401,933 down to 15,002,434,310), probably
because we spend less time allocating SymbolBodies.
The new mechanism by which symbols are added to the symbol table is by calling
add* functions on the SymbolTable.
In this patch, I handle local symbols by storing them inside "unparented"
SymbolBodies. This is suboptimal, but if we do want to try to avoid allocating
these SymbolBodies, we can probably do that separately.
I also removed a few members from the SymbolBody class that were only being
used to pass information from the input file to the symbol table.
This patch implements the new design for the ELF linker only. I intend to
prepare a similar patch for the COFF linker.
[1] http://lists.llvm.org/pipermail/llvm-dev/2016-April/098832.html
Differential Revision: http://reviews.llvm.org/D19752
llvm-svn: 268178
There seems to be no reason to keep st_size of undefined symbols.
This patch removes the member for it. This patch will change outputs
in cases that undefined symbols are copied to output, but I think
this is unimportant.
Differential Revision: http://reviews.llvm.org/D19574
llvm-svn: 267826
The semantics of the -u flag are to load the lazy symbol named by the flag. We
were previously relying on this behavior falling out of symbol resolution
against a synthetic undefined symbol, but that didn't quite give us the
correct behavior, so we needed a flag to mark symbols created with -u so
we could treat them specially in the writer. However, it's simpler and less
error prone to implement the required behavior directly and remove the flag.
This fixes an issue where symbols loaded with -u would receive hidden
visibility even when the definition in an object file had wider visibility.
Differential Revision: http://reviews.llvm.org/D19560
llvm-svn: 267639
This remove a fixme, cleans up the weak undef interaction with archives and
lets us keep weak undefs still weak if they resolve to shared.
llvm-svn: 267555
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
These are properties of a symbol name, rather than a particular instance
of a symbol in an object file. We can simplify the code by collecting these
properties in Symbol.
The MustBeInDynSym flag has been renamed ExportDynamic, as its semantics
have been changed to be the same as those of --dynamic-list and
--export-dynamic-symbol, which do not cause hidden symbols to be exported.
Differential Revision: http://reviews.llvm.org/D19400
llvm-svn: 267183
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
We never need to iterate over the K,V pairs, so we can avoid copying the
key as MapVector does.
This is a small speedup on most benchmarks.
llvm-svn: 266364
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 each archive file was reported no matter were it's member used or not,
like:
lib/libLLVMSupport.a
Now lld prints line for each used internal file, like:
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/StringSaver.cpp.o)
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o)
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.c.o)
That should be consistent with what gold do.
This fixes PR27243.
Differential revision: http://reviews.llvm.org/D19011
llvm-svn: 266220
This simplifies the code by allowing us to remove the visibility argument
to functions that create synthetic symbols.
The only functional change is that the visibility of the MIPS "_gp" symbol
is now hidden. Because this symbol is defined in every executable or DSO, it
would be difficult to observe a visibility change here.
Differential Revision: http://reviews.llvm.org/D19033
llvm-svn: 266208
Now MustBeInDynSym is only true if the symbol really must be in the
dynamic symbol table.
IsUsedInRegularObj is only true if the symbol is used in a .o or -u. Not
a .so or a .bc.
A benefit is that this is now done almost entirilly during symbol
resolution. The only exception is copy relocations because of aliases.
This includes a small fix in that protected symbols in .so don't force
executable symbols to be exported.
This also opens the way for implementing internalize for -shared.
llvm-svn: 265826
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
We have to differentiate undefined symbols from bitcode and undefined
symbols from other sources.
Undefined symbols from bitcode should not inhibit the symbol being
internalized. Undefined symbols from other sources should.
llvm-svn: 265536
Make sure to copy the MustBeInDynSym field when replacing shared symbols with
bitcode symbols, and when replacing bitcode symbols with regular symbols
in addCombinedLtoObject. Fixes interposition of DSO symbols with bitcode
symbols in the main executable.
Differential Revision: http://reviews.llvm.org/D18780
llvm-svn: 265371
Our symbol representation was redundant, and some times would get out of
sync. It had an Elf_Sym, but some fields were copied to SymbolBody.
Different parts of the code were checking the bits in SymbolBody and
others were checking Elf_Sym.
There are two general approaches to fix this:
* Copy the required information and don't store and Elf_Sym.
* Don't copy the information and always use the Elf_Smy.
The second way sounds tempting, but has a big problem: we would have to
template SymbolBody. I started doing it, but it requires templeting
*everything* and creates a bit chicken and egg problem at the driver
where we have to find ELFT before we can create an ArchiveFile for
example.
As much as possible I compared the test differences with what gold and
bfd produce to make sure they are still valid. In most cases we are just
adding hidden visibility to a local symbol, which is harmless.
In most tests this is a small speedup. The only slowdown was scylla
(1.006X). The largest speedup was clang with no --build-id, -O3 or
--gc-sections (i.e.: focus on the relocations): 1.019X.
llvm-svn: 265293
If a symbol is defined in an archive, when we replace its body
the isUsedInRegularObj wasn't set correctly. Internalize makes
its decision based on that bit so we ended up internalizing
symbols that we shouldn't (because they're referenced).
This should fix. Thanks to Peter and Rafael for discussion
and help diagnosing the issue!
Found during LTO of unittests.
llvm-svn: 265208
Some optimizations, e.g. SimplifyLibCalls, can replace functions with
others as part of the lowering, e.g. printf => puts.
The new symbols don't have the isUsedInRegularObj flag set so they
don't get included in the final symbol table (and dynamic symbol
table), and the dynamic linker gets confused. Include them as a fix.
Differential Revision: http://reviews.llvm.org/D18357
llvm-svn: 264688
The code for LTO has been growing, so now is probably a good time to
move it to its own file. SymbolTable.cpp is for symbol table, and
because compiling bitcode files are semantically not a part of
symbol table, this is I think a good thing to do.
http://reviews.llvm.org/D18370
llvm-svn: 264091
-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
which was reverted because included
unrelative changes by mistake.
Original commit message:
[ELF] - Change all messages to lowercase to be consistent.
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263337
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263252
In lld we usually avoid hash lookups. In addition to that, IR names are
not fully mangled, so it is best to avoid using them whenever possible.
llvm-svn: 263248
It was discussed to make all messages be
lowercase to be consistent with clang.
(also reverts the r263128 which fixed
build bot fail after r263125)
Original commit message:
[ELF] - Consistent spelling for error/warning messages
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263240
Summary:
More generally, appending linkage is a special case that we don't want
to create a SymbolBody for.
Reviewers: rafael, ruiu
Subscribers: Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18012
llvm-svn: 263179
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263125
Summary:
This implements another part of -save-temps.
After this, the only remaining part is dumping the optimized bitcode. But
currently LLD's LTO doesn't have a non-intrusive place to put this.
Eventually we probably will and it will make sense to add it then.
Reviewers: ruiu, rafael
Subscribers: joker.eph, Bigcheese, llvm-commits
Differential Revision: http://reviews.llvm.org/D18009
llvm-svn: 263070
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
Summary:
At the very least we hit
Assertion failed: (((Flags & RF_HaveUnmaterializedMetadata) || Node->isResolved()) && "Unexpected unresolved node"), function MapMetadataImpl, file /Users/Sean/pg/llvm/lib/Transforms/Utils/ValueMapper.cpp, line 375.
on the included test case.
We currently do things like parse the module twice to keep the
implementation minimal. I think it makes sense to add start with eager
loading for similar reasons.
Reviewers: rafael
Subscribers: ruiu, Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17982
llvm-svn: 263045
Get rid of few accessors in that class, and replace
them with direct fields access.
Differential revision: http://reviews.llvm.org/D17879
llvm-svn: 262796
This has a few advantages:
* If lld selected a non bitcode symbol, be the bitcode GV is not merged
* lib/Linker is not redoing symbol resolution.
llvm-svn: 262773
SymbolBody constructor and friends take isFunc and isTLS boolean arguments.
ELF symbols have already a type so than be easily passed as argument.
If we want to support another type, this scheme is not good enough, that is,
the current code logic would require passing another `bool isObject` around.
Up to two argument, this stretching exercise was a little bit goofy but
still acceptable, but with more types to support, is just too much, IMHO.
Change the code so that the type is passed instead.
Differential Revision: http://reviews.llvm.org/D17871
llvm-svn: 262684
A weak undefined should not fetch archive members, so we have to keep
the Lazy symbol.
That means the lazy symbol has to encode information about the original
weak undef.
Fixes pr25762.
llvm-svn: 261591
The variable was marking various cases where a symbol must be included
in the dynamic symbol table. Being used by a dynamic relocation was only
one of them.
llvm-svn: 259889
If object files are drawn from archive files, the error message should
be something like "conflict symbols in foo.a(bar.o) and baz.o" instead
of "conflict symbols in bar.o and baz.o". This patch implements that.
llvm-svn: 259475
In many situations, we don't want to exit at the first error even in the
process model. For example, it is better to report all undefined symbols
rather than reporting the first one that the linker picked up randomly.
In order to handle such errors, we don't need to wrap everything with
ErrorOr (thanks for David Blaikie for pointing this out!) Instead, we
can set a flag to record the fact that we found an error and keep it
going until it reaches a reasonable checkpoint.
This idea should be applicable to other places. For example, we can
ignore broken relocations and check for errors after visiting all relocs.
In this patch, I rename error to fatal, and introduce another version of
error which doesn't call exit. That function instead sets HasError to true.
Once HasError becomes true, it stays true, so that we know that there
was an error if it is true.
I think introducing a non-noreturn error reporting function is by itself
a good idea, and it looks to me that this also provides a gradual path
towards lld-as-a-library (or at least embed-lld-to-your-program) without
sacrificing code readability with lots of ErrorOr's.
http://reviews.llvm.org/D16641
llvm-svn: 259069
On MIPS O32 ABI, _gp_disp is a magic symbol designates offset between
start of function and gp pointer into GOT. To make seal with such symbol
we add new method addIgnoredStrong(). It adds ignored symbol with global
binding to prevent the symbol substitution. The addIgnored call is not
enough here because this call adds a weak symbol which might be
substituted by symbol from shared library.
Differential Revision: http://reviews.llvm.org/D16084
llvm-svn: 257449
We used to have code in SymbolTable constructor to add entry symbols, etc.
That code has been moved to Driver. We can remove the constructor.
llvm-svn: 257214
For historical reasons, some add* functions for SymbolTable returns a
pointer to a SymbolBody, while some are not. This patch is to make them
consistently return a pointer to a newly added symbol.
llvm-svn: 257211
In this patch, all symbols are resolved normally and then wrap options
are applied. Renaming is implemented by mutating `Body` pointers of
Symbols. (As a result, Symtab.find(SymbolName)->getName() may return
a string that's different from SymbolName, but that is by design.
I designed the symbol and the symbol table to allow this kind of
operations.)
http://reviews.llvm.org/D15896
llvm-svn: 257075
Unlike ObjectFile or ArchiveFile, SharedFile had two parse functions,
parseSoName() and parse(). parse must have been called after parseSoName,
but that requirement was not obvious from their names. (So it looked
like you could call parse() on a shared object file right away.)
This patch rename parseRest. It is now obvious that there's no single
parse function for the shared object file.
llvm-svn: 256898
George Rimar