Convert all common symbols to regular symbols after scan.
This means that the downstream code does not to handle common symbols as a special case.
Differential Revision: https://reviews.llvm.org/D38137
llvm-svn: 314495
This is "Bug 34688 - lld much slower than bfd when linking the linux kernel"
Inside copyRelocations() we have O(N*M) algorithm, where N - amount of
relocations and M - amount of symbols in symbol table. It isincredibly slow
for linking linux kernel.
Patch creates local search tables to speedup.
With this fix link time goes for me from 12.95s to 0.55s what is almost 23x
faster. (used release LLD).
Differential revision: https://reviews.llvm.org/D38129
llvm-svn: 314282
SymbolTable::insert() is a hot path function. When linking a clang debug
build, the function is called 3.7 million times. The total amount of "Name"
string contents is 300 MiB. That means this `Name.find("@@")` scans almost
300 MiB of data. That's far from negligible.
StringRef::find(StringRef) uses a sophisticated algorithm, but the
function is slow for a short needle. This patch replaces it with
StringRef::find(char).
This patch alone speeds up a clang debug build link time by 0.5 seconds
from 8.2s to 7.7s. That's 6% speed up. It seems too good for this tiny
change, but looks like it's real.
llvm-svn: 314192
[Synopsys]
Using function elf::link(...) leads to segmentation fault on its second call. First call finishes correctly.
[Solution]
Clear the rest of globals.
Reviewed by: George Rimar and Rui Ueyama
Differential Revision: http://reviews.llvm.org/D38131
llvm-svn: 314108
Previously`InX::Got` and InX::MipsGot synthetic sections
were not removed if ElfSym::GlobalOffsetTable was defined.
ElfSym::GlobalOffsetTable is a symbol for _GLOBAL_OFFSET_TABLE_.
Patch moves ElfSym::GlobalOffsetTable check out from removeUnusedSyntheticSections.
Also note that there was no point to check ElfSym::GlobalOffsetTable for MIPS case
because InX::MipsGot::empty() always returns false for non-relocatable case, and in case
of relocatable output we do not create special symbols anyways.
Differential revision: https://reviews.llvm.org/D37623
llvm-svn: 314099
When -verbose is specified, patch outputs names of each input orphan section
assigned to output.
Differential revision: https://reviews.llvm.org/D37517
llvm-svn: 314098
Previously when BC file had global variable that was accessed from script,
it was optimized away or inlined by IPO.
In this patch I add symbols at left side of assignment expression as LinkerRedefined,
what prevents optimization for them.
Differential revision: https://reviews.llvm.org/D37059
llvm-svn: 314097
We used to sort and uniquify CU vectors, but looks like CU vectors in
.gdb_index sections created by gold are not guaranteed to be sorted.
llvm-svn: 314095
We used to use std::set to uniquify CU vector elements, but as we know,
std::set is pretty slow. Fortunately we didn't actually have to use a
std::set here. This patch replaces it with std::vector.
With this patch, lld's -gdb-index overhead when linking a clang debug
build is now about 1 second (8.65 seconds without -gdb-index vs 9.60
seconds with -gdb-index). Since gold takes more than 6 seconds to create
a .gdb_index for the same output, our number isn't that bad.
llvm-svn: 314094
Previously, we had two levels of hash table lookup. The first hash
lookup uses CachedHashStringRefs as keys and returns offsets in string
table. Then, we did the second hash table lookup to obtain GdbSymbol
pointers. But we can directly map strings to GDbSymbols.
One test file is updated in this patch because we no longer have a '\0'
byte at the start of the string pool, which was automatically inserted
by StringTableBuilder.
This patch speeds up Clang debug build (with -gdb-index) link time by
0.3 seconds.
llvm-svn: 314092
This change alone speeds up linking of Clang debug build with -gdb-index
by 1.2 seconds, from 12.5 seconds to 11.3 seconds. (Without -gdb-index,
lld takes 8.5 seconds to link the same input files.)
llvm-svn: 314090
In order to keep track of symbol renaming, we used to have
Config->SymbolRenaming, and whether a symbol is in the map or not
affects its symbol attribute (i.e. "LinkeRedefined" bit).
This patch adds "CanInline" bit to Symbol to aggreagate symbol
information in one place and removed the member from Config since
no one except SymbolTable now uses the table.
llvm-svn: 314088
This patch rewrites a part of GdbIndexSection to address the following
issues in the previous implementation:
- Previously, some struct declarations were in GdbIndex.h while they
were not used in GdbIndex.cpp. Such structs are moved to
SyntheticSection.h.
- The actual implementation were split into GdbIndexSection and GdbHash
section, but that separation didn't make much sense. They are now
unified as GdbIndexSection.
In addition to the above changes, this patch splits functions, rename
variables and remove redundant functions/variables to generally improve
code quality.
llvm-svn: 314084
For ARM thunks, the `movt` half of the relocation was using an incorrect
offset (it was off by 4 bytes). The original intent seems to have been
for the offset to have been relative to the current instruction, in
which case the difference of 4 makes sense. As the code stands, however,
the offset is always calculated relative to the start of the thunk
(`P`), and so the `movw` and `movt` halves should use the same offset.
This requires a very particular offset between the thunk and its target
to be triggered, and it results in the `movt` half of the relocation
being off-by-one.
The tests here use ARM-Thumb interworking thunks, since those are the
only ARM thunks currently implemented. I actually encountered this with
a range extension thunk (having Peter's patches cherry-picked locally),
but the underlying issue is identical.
Differential Revision: https://reviews.llvm.org/D38112
llvm-svn: 313915
This patch goes back to considering ForceAbsolute in moveAbsRight, but
only if the second argument is not already absolute.
With this we can handle "foo + ABSOLUTE(foo)" and "ABSOLUTE(foo) + foo".
llvm-svn: 313800
The idea of this function is to simplify the implementation of binary
operators like add.
A value might be absolute because of an ABSOLUTE expression, but it
still depends on the value of a section and we might not be able to
evaluate it early. We should keep such values on the LHS, so that we
can delay the evaluation.
We can now handle both "1 + ABSOLUTE(foo)" and "ABSOLUTE(foo) + 1".
llvm-svn: 313794
The previous logic was to try to detect if a linker script defined _gp
by checking !ElfSym::MipsGp->Value. That doesn't work in all cases as
the assigned value can be 0.
We now just always defined it Writer.cpp and always overwrite it
afterwards if needed.
llvm-svn: 313788
Normally to find the offset of a value in a section, we have to
compute the value since the alignment is defined on the final address.
If the alignment is trivial, we can skip the value computation. This
allows us to know the offset even in cases where we cannot yet know
the value.
llvm-svn: 313777
We try to evaluate expressions early when possible, but it is not
possible to evaluate them early if they are based on a section.
Before we would get this wrong on ABSOLUTE expressions.
llvm-svn: 313764
Its a PR34648 which was a segfault that happened because
we stored pointers to elements in DenseMap.
When DenseMap grows such pointers are invalidated.
Solution implemented is to keep elements by pointer
and not by value.
Differential revision: https://reviews.llvm.org/D38034
llvm-svn: 313741
EhSectionPiece used to have a pointer to a section, but that pointer was
mostly redundant because we almost always know what the section is without
using that pointer. This patch removes the pointer from the struct.
This patch also use uint32_t/int32_t instead of size_t to represent
offsets that are hardly be larger than 4 GiB. At the moment, I think it is
OK even if we cannot handle .eh_frame sections larger than 4 GiB.
Differential Revision: https://reviews.llvm.org/D38012
llvm-svn: 313697
CieRecord is a struct containing a CIE and FDEs, but oftentimes the
struct itself is named `Cie` which caused some confusion. This patch
renames them `CieRecords` or `Rec`.
llvm-svn: 313681
Given a linker script that ends in
.some_sec { ...} ;
__stack_start = .;
. = . + 0x2000;
__stack_end = .;
lld would put orphan sections like .comment before __stack_end,
corrupting the intended meaning.
The reason we don't normally move orphans past assignments to . is to
avoid breaking
rx_sec : { *(rx_sec) }
. = ALIGN(0x1000);
/* The RW PT_LOAD starts here*/
but in this case, there is nothing after and it seems safer to put the
orphan section last. This seems to match bfd's behavior and is
convenient for writing linker scripts that care about the layout of
SHF_ALLOC sections, but not of any non SHF_ALLOC sections.
llvm-svn: 313646
This is PR34506.
Imagine we have 2 sections the same name but different COMDAT groups:
.section .foo,"axG",@progbits,bar,comdat
.section .foo,"axG",@progbits,zed,comdat
When linking relocatable we do not merge SHT_GROUP sections. But still would merge
both input sections .foo into single output section .foo.
As a result we will have 2 different SHT_GROUPs containing the same section, what
is wrong.
Patch fixes the issue, preventing merging SHF_GROUP sections with any others.
Differential revision: https://reviews.llvm.org/D37574
llvm-svn: 313621
We crashed when --emit-relocs was used
and relocated section was collected by GC.
Differential revision: https://reviews.llvm.org/D37561
llvm-svn: 313620
This patch removes lot of static Instances arrays from different input file
classes and introduces global arrays for access instead. Similar to arrays we
have for InputSections/OutputSectionCommands.
It allows to iterate over input files in a non-templated code.
Differential revision: https://reviews.llvm.org/D35987
llvm-svn: 313619
EhSectionPiece inherited from SectionPiece, but we did not actually use
EhSectionPiece objects as SectionPiece ojbects. They were handled as
distinct types. So it didn't make much sense to use inheritance.
llvm-svn: 313587
"Repl" member is guranteed to have a non-null pointer. If an input
section is not merged by ICF, "Repl" points to "this". Otherwise, it
points to some other section. It must not be NULL.
llvm-svn: 313556
This is not really OK in C++11, and GCc triggers a warning.
We can switch back to default arguments when C++14 will be the
minimum version of the standard supported, see:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#974
Ack'ed by Rafael.
llvm-svn: 313550
Ben Dunbobbin