| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 316733
|
|
|
|
| |
llvm-svn: 316731
|
|
|
|
|
|
|
|
| |
Previously, EhFrameSection pushes data to EhFrameHdr by calling addFde
function. By making EhFrameHdr pull data from EhFrameSection, we can
eliminate a member from EhFrameHdr.
llvm-svn: 316730
|
|
|
|
| |
llvm-svn: 316729
|
|
|
|
|
|
|
| |
In a rare situation, the function can fail (e.g. it fails if it cannot
open /dev/urandom.)
llvm-svn: 316726
|
|
|
|
| |
llvm-svn: 316716
|
|
|
|
|
|
|
| |
Because of the same reason as r316600, I don't think we need a guard
against empty relocations.
llvm-svn: 316710
|
|
|
|
| |
llvm-svn: 316707
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When LLD do ICF for 2 identical sections it leaves 2 duplicate entries in .eh_frame
pointing to the same address. After that it fixes .eh_frame_header's header,
so that it says it contains single FDE, though section itself contains 2
(it contains garbage data at tail).
As a result excessive entries in .eh_frame and excessive dummy data in .eh_frame_header
emited to output. Patch fixes that. This is PR34518.
Differential revision: https://reviews.llvm.org/D38998
llvm-svn: 316648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D39259
llvm-svn: 316624
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By assuming that mergeable input sections are smaller than 4 GiB,
lld's memory usage when linking clang with debug info drops from
2.788 GiB to 2.019 GiB (measured by valgrind, and that does not include
memory space for mmap'ed files). I think that's a reasonable assumption
given such a large RAM savings, so this patch.
According to valgrind, gold needs 3.54 GiB of RAM to do the same thing.
NB: This patch does not introduce a limitation on the size of
output sections. You can still create sections larger than 4 GiB.
llvm-svn: 316280
|
|
|
|
| |
llvm-svn: 316078
|
|
|
|
|
|
| |
It was at wrong place.
llvm-svn: 316077
|
|
|
|
|
|
|
| |
They are special in that they they need to be in the hash table iff we
are linking an executable that preempts them.
llvm-svn: 316065
|
|
|
|
|
|
|
|
| |
This reverts commit r316051.
It fails on a bot.
llvm-svn: 316058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original patch was reported to break a libcxx bot. Unfortunately I
could not reproduce the issue and the bot log is not available anymore.
This patch changes the handling of shared symbols. I will watch the
bot and see it breaks.
Original message:
--------------------------------------------------------------
Handle shared and lazy symbol in the gnu hash construction.
We were not considering those symbols undefined and they could end up
in the end of the dynamic symbol table.
--------------------------------------------------------------
llvm-svn: 316051
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original patch was reported to break a libcxx bot. Unfortunately
I could not reproduce the issue and the bot log is not available anymore.
This patch changes the handling of just lazy symbols. I will watch the
bot and see it breaks.
Original message:
--------------------------------------------------------------
Handle shared and lazy symbol in the gnu hash construction.
We were not considering those symbols undefined and they could end up
in the end of the dynamic symbol table.
--------------------------------------------------------------
llvm-svn: 316004
|
|
|
|
|
|
| |
It broke check-libcxx with stage1-clang and stage1-lld.
llvm-svn: 315803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This will allow using the functionality from other linkers. It is also
a prerequisite for sharing the error logging code.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: emaste, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38822
llvm-svn: 315725
|
|
|
|
|
|
|
| |
We were not considering those symbols undefined and they could end up
in the end of the dynamic symbol table.
llvm-svn: 315721
|
|
|
|
|
|
|
| |
IsLocal member is initialized by the constructor and will never change.
So we don't want to make it directly accessible.
llvm-svn: 315667
|
|
|
|
|
|
| |
Because it was a redundant accessor to Symbol's public member.
llvm-svn: 315609
|
|
|
|
|
|
|
|
|
| |
It doesn't make sense to link from an alloc section to a non alloc
one as we were doing.
This matches the behavior of both gold and bfd.
llvm-svn: 315584
|
|
|
|
|
|
|
| |
Even though they are called sequentially, they are separate
operations, so it is better to split it.
llvm-svn: 315422
|
|
|
|
|
|
|
|
|
|
| |
"Commands" was ambiguous because in the linker script, everything is
a command. We used to handle only SECTIONS commands, and at the time,
it might make sense to call them the commands, but it is no longer
the case. We handle not only SECTIONS but also MEMORY, PHDRS, VERSION,
etc., and they are all commands.
llvm-svn: 315409
|
|
|
|
|
|
|
|
|
|
|
|
| |
The condition whether a section is alive or not by default
is becoming increasingly complex, so the decision of garbage
collection is spreading over InputSection.h and MarkLive.cpp,
which is not a good state.
This moves the code to MarkLive.cpp, to keep the file the central
place to make decisions about garbage collection.
llvm-svn: 315384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing linker scripts, LLD previously started with a '.' value of 0,
regardless of the internal default image base for the target, and regardless of
switches such as --image-base. It seems reasonable to use a different image base
value when using linker scripts and --image-base is specified, since otherwise the
switch has no effect. This change does this, as well as removing unnecessary
initialisation of Dot where it is not used.
The default image base should not be used when processing linker
scripts, because this will change the behaviour for existing linker script users,
and potentially result in invalid output being produced, as a subsequent assignment
to Dot could move the location counter backwards. Instead, we maintain the existing
behaviour of starting from 0 if --image-base is not specified.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D38360
llvm-svn: 315293
|
|
|
|
| |
llvm-svn: 315268
|
|
|
|
|
|
| |
I feel it is easier to understand without this function.
llvm-svn: 315140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLD produces broken .dynamic section when --no-rosegment and at least
one of following options is present:
1) -z rodynamic is given.
2) MIPS target.
That happens because code that writes .dynamic assumes target buffer
is zero-filled, what can be not true after LLD fills it with trap
instructions. With one of two options above, .dynamic becomes
SHF_ALLOC section, so can be affected.
Differential revision: https://reviews.llvm.org/D38580
llvm-svn: 315054
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We produce broken output currently.
Code that writes .dynsym assumes output buffer is zero-filled,
though that is not always true. When --no-rosegment is given,
buffer can be filled with trap instructions. Patch fixes the issue.
It is relative with PR34705.
Differential revision: https://reviews.llvm.org/D38579
llvm-svn: 315053
|
|
|
|
| |
llvm-svn: 315042
|
|
|
|
|
|
|
|
|
|
| |
std::thread::hardware_concurrency."
This reverts commit r314924.
The required llvm patch was recommitted.
llvm-svn: 314933
|
|
|
|
|
|
|
|
| |
std::thread::hardware_concurrency.
This reverts commit r314810 because r314809 was reverted.
llvm-svn: 314924
|
|
|
|
|
|
|
| |
We no longer call reserveSpace more than once, so it can be merged with
its constructor.
llvm-svn: 314867
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reporting a symbol conflict, LLD parses the debug info to report
source location information. Sections have not been decompressed at this
point, so if an object file contains zlib compressed debug info, LLD
ends up passing this compressed debug info to the DWARF parser, which
causes debug info parsing failures and can trigger assertions in the
parser (as the test case demonstrates).
Decompress debug sections when constructing the LLDDwarfObj to avoid
this issue. This doesn't handle GNU-style compressed debug info sections
(.zdebug_*), which at present are simply ignored by LLDDwarfObj; those
can be done in a follow-up.
Differential Revision: https://reviews.llvm.org/D38491
llvm-svn: 314866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue with std::thread::hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314810
|
|
|
|
| |
llvm-svn: 314746
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently LLD calls the `isMicroMips` routine to determine type of PLT entries
needs to be generated: regular or microMIPS. This routine checks ELF
header flags in the `FirstObj` to retrieve type of linked object files.
So if the first file does not contain microMIPS code, LLD will generate
PLT entries with regular (non-microMIPS) code only.
Ideally, if a PLT entry is referenced by microMIPS code only this entry
should contain microMIPS code, if a PLT entry is referenced by regular
code this entry should contain regular code. In a "mixed" case the PLT
entry can be either microMIPS or regular, but each "cross-mode-call" has
additional cost.
It's rather difficult to implement this ideal solution. But we can
assume that if there is an input object file with microMIPS code, the
most part of the code is microMIPS too. So we need to deduce type of PLT
entries based on finally calculated ELF header flags and do not check
only the first input object file.
This change implements this.
- The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function
called from the `LinkerDriver::link`. Result is stored in
the Configuration::MipsEFlags field.
- The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags`
field to get and check calculated ELF flags.
- New types of PLT records created when necessary.
Differential revision: https://reviews.llvm.org/D37747
llvm-svn: 314675
|
|
|
|
| |
llvm-svn: 314592
|
|
|
|
| |
llvm-svn: 314590
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
String merging is one of the most time-consuming functions in lld.
This patch parallelize it to speed it up. On my 2-socket 20-core
40-threads Xeon E5-2680 @ 2.8 GHz machine, this patch shorten the
clang debug build link time from 7.11s to 5.16s. It's a 27%
improvement and actually pretty noticeable. In this test condition,
lld is now 4x faster than gold.
Differential Revision: https://reviews.llvm.org/D38266
llvm-svn: 314588
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Detemplation of one more synthetic section.
Differential revision: https://reviews.llvm.org/D38241
llvm-svn: 314283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This patch alone is neutral in terms of code readability, but this
change makes a following patch easier to read.
llvm-svn: 314181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|