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
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 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
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 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
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
The DenseMap doesn't store hash results. This means that when it is
resized it has to recompute them.
This patch is a small hack that wraps the StringRef in a struct that
remembers the hash value. That way we can be sure it is only hashed
once.
llvm-svn: 266357
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
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
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
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
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
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
I am working on adding LTO support to the new ELF lld.
In order to do that, it will be necessary to represent defined and
undefined symbols that are not from ELF files. One way to do it is to
change the symbol hierarchy to look like
Defined : SymbolBody
Undefined : SymbolBody
DefinedElf<ELFT> : Defined
UndefinedElf<ELFT> : Undefined
Another option would be to use bogus Elf_Sym, but I think that is
getting a bit too hackish.
This patch does the Undefined/UndefinedElf. Split. The next one
will do the Defined/DefinedElf split.
llvm-svn: 256289
The function was used only in Writer.cpp and did not depend on SymbolTable.
There is no reason to have that function in SymbolTable.cpp.
llvm-svn: 255850
addELFFile was called only from addFile, and what it did was actually
just adding a file to the symbol table. There seems to be no reason
to separate the two.
llvm-svn: 255839
The `_gp_disp` is a magic symbol designates offset between start of
function and gp pointer into GOT. Only `R_MIPS_HI16` and `R_MIPS_LO16`
relocations are permitted with `_gp_disp`. The patch adds the `_gp_disp`
as an ignored symbol and adjusts symbol value before call the `relocateOne`
for `R_MIPS_HI16/LO16` relocations.
Differential Revision: http://reviews.llvm.org/D15480
llvm-svn: 255768
This patch implements R_MIPS_GOT16 relocation for global symbols in order to
generate some entries in GOT. Only reserved and global entries are supported
for now. For the detailed description about GOT in MIPS, see "Global Offset
Table" in Chapter 5 in the followin document:
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
In addition, the platform specific symbol "_gp" is added, see "Global Data
Symbols" in Chapter 6 in the aforementioned document.
Differential revision: http://reviews.llvm.org/D14211
llvm-svn: 252275
Section garbage collection is a feature to remove unused sections
from outputs. Unused sections are sections that cannot be reachable
from known GC-root symbols or sections. Naturally the feature is
implemented as a mark-sweep garbage collector.
In this patch, I added Live bit to InputSectionBase. If and only
if Live bit is on, the section will be written to the output.
Starting from GC-root symbols or sections, a new function, markLive(),
visits all reachable sections and sets their Live bits. Writer then
ignores sections whose Live bit is off, so that such sections are
excluded from the output.
This change has small negative impact on performance if you use
the feature because making sections means more work. The time to
link Clang changes from 0.356s to 0.386s, or +8%.
It reduces Clang size from 57,764,984 bytes to 55,296,600 bytes.
That is 4.3% reduction.
http://reviews.llvm.org/D13950
llvm-svn: 251043
This patch is to use ELFT instead of Is64Bits to template OutputSection
and its subclasses. This increases code size slightly because it creates
two identical functions for some classes, but that's only 20 KB out of
33 MB, so it's negligible.
This is as per discussion with Rafael. He's not fan of the idea but OK
with this. We'll revisit later to this topic.
llvm-svn: 250466
If a section name is valid as a C identifier (which is rare because of
the leading '.'), linkers are expected to define __start_<secname> and
__stop_<secname> symbols. They are at beginning and end of the section,
respectively. This is not requested by the ELF standard, but GNU ld and
gold provide this feature.
llvm-svn: 250432
"finalize" does not give a hint about what that function is actually
going to do. This patch make it more specific by renaming scanShlibUndefined.
Also add a comment that we basically ignore undefined symbols in DSOs except
this function.
llvm-svn: 250191
BSD's DSO files have undefined symbol "__progname" which is defined
in crt1.o. On that system, both user programs and system shared
libraries depend on each other.
In general, we need to put symbols defined by user programs which are
referenced by shared libraries to user program's .dynsym.
http://reviews.llvm.org/D13637
llvm-svn: 250176
SymbolTable was not a right place for initialization. We had to do that
because Driver didn't know what type of ELF objects are being handled.
We taught Driver that, so we can now move this code to Driver.
llvm-svn: 249904
SymbolTable was not a template class. Instead we had switch-case-based
type dispatch to call desired functions. We had to do that because
SymbolTable was created before we know what ELF type objects had been
passed.
Every time I tried to add a new function to the symbol table, I had to
define a dispatcher which consist of a single switch statement.
It also brought an restriction what the driver can do. For example,
we cannot add undefined symbols before any files are added to the symbol
table. That's because no symbols can be added until the symbol table
knows the ELF type, but when it knows about that, it's too late.
In this patch, the driver makes a decision on what ELF type objects
are being handled. Then the driver creates a SymbolTable object for
an appropriate ELF type.
http://reviews.llvm.org/D13544
llvm-svn: 249902
Add symbol specified with -u as undefined which may cause additional
object files from archives to be linked into the resulting binary.
Differential Revision: http://reviews.llvm.org/D13345
llvm-svn: 249295
This is just enough to get PLT working on 32 bit x86.
The idea behind using a virtual interface is that it should be easy to
convert any of the functions to template parameters if any turns out to be
performance critical.
llvm-svn: 248308
We used to sort the symbols at the very end, but we need to know the order
earlier so that we can create reference to them in the dynamic relocations.
Thanks to Igor Kudrin for pointing out the problem.
llvm-svn: 247911
They are not fully functional yet, but this implements enough support for lld
itself to read them.
With that, delete the .so binary we were using for tests and start eating our
own dog food.
llvm-svn: 247487
With this patch only the name is set. I will set the other fields shortly.
For now the table doesn't include local symbols. This is equivalent to using
--discard-all with gnu ld. This is OK for now since the symbols are not
needed for execution and for testing symbol resolution we only need the
global symbols.
llvm-svn: 245044
When we were using a std::sort over all the chunks we needed to put them in a
single storage.
Now that we just iterate over them and use a map to find the output section,
we can avoid allocating the temporary storage.
llvm-svn: 243980
This is a direct port of the new PE/COFF linker to ELF.
It can take a single object file and generate a valid executable that executes at the first byte in the text section.
llvm-svn: 242088
Rafael Espindola