Previously, we added garbage-collected symbols to the symbol table
and filter them out when we were writing symbols to the file. In
this patch, garbage-collected symbols are filtered out from beginning.
llvm-svn: 261064
Previously, if both A and B are ".ctors", both compCtors(A, B) and
compCtors(B, A) are true, which is a violation of the strict weak
ordering because such function is not antisymmetric.
llvm-svn: 260633
Global constructors and destructors are guaranteed to be called
in the order as they appear in a translation unit. So we don't want
to mess up the order if they have the same priority.
llvm-svn: 260463
This basically reverts commit r260073 because it is found that
augmentation strings don't always start with "zR". It is reported
as https://llvm.org/bugs/show_bug.cgi?id=26541.
llvm-svn: 260294
This is the function equivalent of a copy relocation.
Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.
The dynamic linker makes sure any shared library uses the plt entry as
the function address.
llvm-svn: 260224
I found that the handling of 'L' character in an augmentation string is
wrong because 'L' means that the next byte is the length field. I could
have fixed that by just skipping the next byte, but I decided to take a
different approach.
Teaching the linker about all the types of CIE internal records just to
skip them is silly. And the code doing that is not actually executed now
(that's why the bug did not cause any issue.) It is because the 'R' field,
which we want to read, is always at beginning of the CIE. So I reduced
the code dramatically by assuming that that's always the case. I want to
see how it works in the wild. If it doesn't work, we can roll this back
(with a fix for 'L').
http://reviews.llvm.org/D16939
llvm-svn: 260073
I removed "CIE/FIE size is too large" error because that was not
checking for correct error conditions. [UINT_MAX - 4, UINT_MAX) is
a correct range as a size of a CIE/FDE record. It's just that the
size cannot be larger than the section size.
llvm-svn: 259951
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
The previous names contained "Local" and "Current", but what we
are handling is always local and current, so they were redundant.
TlsIndex comes from "tls_index" struct that Ulrich Drepper is using
in this document to describe this data structure in GOT.
llvm-svn: 259852
Another case where we currently have almost duplicated code is the
creation of dynamic relocations. First to decide if we need one, then to
decide what to write.
This patch fixes it by passing more information from the relocation scan
to the section writing code. This is the same idea used for r258723.
I actually think it should be possible to simplify this further by
reordering things a bit in the writer. For example, we should be able to
represent almost every position in the file with an OutputSeciton and
offset. When writing it out we then just need to add the offset to the
OutputSection VA.
llvm-svn: 259829
-Bsymbolic-functions:
When creating a shared library, bind references to global
function symbols to the definition within the shared library, if any.
This patch also fixed behavior of already existent -Bsymbolic:
previously PLT entries were created even if -Bsymbolic was specified.
Differential revision: http://reviews.llvm.org/D16411
llvm-svn: 259481
Previously, the methods to get symbol addresses were somewhat scattered
in many places. You can use getEntryAddr returns the address of the symbol,
but if you want to get the GOT address for the symbol, you needed to call
Out<ELFT>::Got->getEntryAddr(Sym). This change adds new functions, getVA,
getGotVA, getGotPltVA, and getPltVA to SymbolBody, so that you can use
SymbolBody as the central place to ask about symbols.
http://reviews.llvm.org/D16710
llvm-svn: 259404
This avoids the need to have reserve and addString in sync.
We avoid hashing the global symbols again. This means that we don't
merge a global symbol that has the same name as some other string, but
that doesn't seem very common. The string table size is the same in
clang an scylladb with or without hashing global symbols again.
llvm-svn: 259136
This function is a predicate that a given relocation can be relaxed.
The previous name implied that it returns true if a given relocation
has already been optimized away.
llvm-svn: 259128
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
This does not solve the problem that we call isGnuIFunc function
both from RelocationSection and from the Writer::scanRelocs, but
this at least should improve readability. I'm taking an incremental
approach to reduce complexity.
llvm-svn: 258753
There are a few cases where we have almost duplicated code.
This patches fixes the simplest: the finalize and write of dynamic
section. Right now they have to have exactly the same structure to
decide if a DT_* entry is needed and then to actually write it.
We cannot just write it to a std::vector in the first pass since
addresses have not been computed yet.
llvm-svn: 258723
Summary: It looks like this snuck through in r256143/D15383.
Reviewers: ruiu, grimar
Differential Revision: http://reviews.llvm.org/D16500
llvm-svn: 258599
In this code, we avoid calling needsCopyRel in writeTo because
we called that function already in scanRelocs. Making the same
decision twice is a waste and has a risk of a bug that we get
inconsistent resuts.
llvm-svn: 258430
Some MIPS relocation (for now R_MIPS_GOT16) requires creation of GOT
entries for symbol not included in the dynamic symbol table. They are
local symbols and non-local symbols with 'local' visibility. Local GOT
entries occupy continuous block between GOT header and regular GOT
entries.
The patch adds initial support for handling local GOT entries. The main
problem is allocating local GOT entries for local symbols. Such entries
should be initialized by high 16-bit of the symbol value. In ideal world
there should be no duplicated entries with the same values. But at the
moment of the `Writer::scanRelocs` call we do not know a value of the
symbol. In this patch we create new local GOT entry for each relocation
against local symbol, though we can exhaust GOT quickly. That needs to
be optimized later. When we calculate relocation we know a final symbol
value and request local GOT entry index. To do that we maintain map
between addresses and local GOT entry indexes. If we start to calculate
relocations in parallel we will have to serialize access to this map.
Differential Revision: http://reviews.llvm.org/D16324
llvm-svn: 258388
Added check for terminator CIE/FDE which has zero data size.
void EHOutputSection<ELFT>::addSectionAux(
...
// If CIE/FDE data length is zero then Length is 4, this
// shall be considered a terminator and processing shall end.
if (Length == 4)
break;
...
After this "Bug 25923 - lld/ELF2 linked application crashes if exceptions were used." is fixed for me. Self link of clang also works.
Initial commit message:
[ELF] - implemented --eh-frame-hdr command line option.
--eh-frame-hdr
Request creation of ".eh_frame_hdr" section and ELF "PT_GNU_EH_FRAME" segment header.
Both gold and the GNU linker support an option --eh-frame-hdr which tell them to construct a header for all the .eh_frame sections. This header is placed in a section named .eh_frame_hdr and also in a PT_GNU_EH_FRAME segment. At runtime the unwinder can find all the PT_GNU_EH_FRAME segments by calling dl_iterate_phdr.
This section contains a lookup table for quick binary search of FDEs.
Detailed info can be found here:
http://www.airs.com/blog/archives/462
Differential revision: http://reviews.llvm.org/D15712
llvm-svn: 257889
--eh-frame-hdr
Request creation of ".eh_frame_hdr" section and ELF "PT_GNU_EH_FRAME" segment header.
Both gold and the GNU linker support an option --eh-frame-hdr which tell them to construct a header for all the .eh_frame sections. This header is placed in a section named .eh_frame_hdr and also in a PT_GNU_EH_FRAME segment. At runtime the unwinder can find all the PT_GNU_EH_FRAME segments by calling dl_iterate_phdr.
This section contains a lookup table for quick binary search of FDEs.
Detailed info can be found here:
http://www.airs.com/blog/archives/462
Differential revision: http://reviews.llvm.org/D15712
llvm-svn: 257753
Summary: This will allow us to remove the AMDGPU support from old ELF.
Reviewers: rafael, ruiu
Differential Revision: http://reviews.llvm.org/D15895
llvm-svn: 257023
String tables in unstripped executable files are fairly large in size.
For example, lld's executable file is about 34.4 MB in my environment,
and of which 3.5 MB is the string table. Efficiency of string table
construction matters.
Previously, the string table was built in an inefficient way. We used
StringTableBuilder to build that and enabled string tail merging,
although tail merging is not effective for the symbol table (you can
only make the string table 0.3% smaller for lld.) Tail merging is
computation intensive task and slow.
This patch eliminates string tail merging.
I changed the way of adding strings to the string table in this patch
too. Previously, strings were added using add() and the same strings
were then passed to getOffset() to get their offsets in the string table.
In this way, getOffset() needs to look up a hash table to get offsets
for given strings. This is a violation of "we look up the symbol table
(or a hash table) only once for each symbol" dogma of the new LLD's
design. Hash table lookup for long C++ mangled names is slow.
I eliminated that lookup in this patch.
In total, this patch improves link time of lld itself about 12%
(3.50 seconds -> 3.08 seconds.)
llvm-svn: 257017
MipsReginfoInputSection is basically just a container of Elf_Mips_Reginfo
struct. This patch makes that struct directly accessible from others.
llvm-svn: 256984
Test did not catch this either, so I`ll improve it and recommit later.
Original commit message:
[ELF] - Optimize .eh_frame section: remove CIE if all FDEs referencing it were removed.
This patch performs little optimization for eh_frame section.
If all FDE`s that referenced CIE are removed then CIE is also removed from output.
That can happen for example when dropping FDEs that point to dropped sections. Testcase showing that is included.
The same optimization was added to ld about 14 years ago: https://sourceware.org/ml/binutils/2001-12/msg00144.html, gold does not do that it seems.
Differential revision: http://reviews.llvm.org/D15564
llvm-svn: 256693
This patch performs little optimization for eh_frame section.
If all FDE`s that referenced CIE are removed then CIE is also removed from output.
That can happen for example when dropping FDEs that point to dropped sections. Testcase showing that is included.
The same optimization was added to ld about 14 years ago: https://sourceware.org/ml/binutils/2001-12/msg00144.html, gold does not do that it seems.
Differential revision: http://reviews.llvm.org/D15564
llvm-svn: 256638
OutputSectionBase already has virtual member functions.
This patch makes addSection() a virtual function to remove code
from Writer::createSections().
llvm-svn: 256436
There are 3 symbol types that a .bc can provide during lto: defined,
undefined, common.
Defined and undefined symbols have already been refactored. I was
working on common and noticed that absolute symbols would become an
oddity: They would be the only symbol type present in a .o but not in
a.bc.
Looking a bit more, other than the special section number they were only
used for special rules for computing values. In that way they are
similar to TLS, and we don't have a DefinedTLS.
This patch deletes it. With it we have a reasonable rule of the thumb
for having a symbol kind: It exists if it has special resolution
semantics.
llvm-svn: 256383
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
This patch changes sequence of applying relocations, moving tls optimized relocation handling code before code for other locals.
Without that change relocation @GOTTPOFF against local symbol caused runtime error ("unrecognized reloc ...").
That change also should fix other tls optimized relocations, but I did not check them, that's a field for another patch.
R_X86_64_GOTTPOFF relocations against locals can be found when linking against libc.a(malloc.o):
000000000036 000600000016 R_X86_64_GOTTPOFF 0000000000000000 libc_tsd_MALLOC - 4
000000000131 000600000016 R_X86_64_GOTTPOFF 0000000000000000 libc_tsd_MALLOC - 4
Differential revision: http://reviews.llvm.org/D15581
llvm-svn: 256145
This relocation is similar to R_*_RELATIVE except that the value used in this relocation is the program address returned by the function, which takes no arguments, at the address of
the result of the corresponding R_*_RELATIVE relocation as specified in the processor-specific ABI. The purpose of this relocation to avoid name lookup for locally defined STT_GNU_IFUNC symbols at load-time.
More info can be found in ifunc.txt from https://sites.google.com/site/x32abi/documents.
Differential revision: http://reviews.llvm.org/D15235
llvm-svn: 256144
R_386_GOTOFF is calculated as S + A - GOT, where:
S - Represents the value of the symbol whose index resides in the relocation entry.
A - Represents the addend used to compute the value of the relocatable field.
GOT - Represents the address of the global offset table.
Differential revision: http://reviews.llvm.org/D15383
llvm-svn: 256143
Rui Ueyama