We were previously using an output offset of -1 for both GC'd and tail
merged pieces. We need to distinguish these two cases in order to filter
GC'd symbols from the symbol table -- we were previously asserting when we
asked for the VA of a symbol pointing into a dead piece, which would end
up asking the tail merging string table for an offset even though we hadn't
initialized it properly.
This patch fixes the bug by using an offset of -1 to exclusively mean GC'd
pieces, using 0 for tail merges, and distinguishing the tail merge case from
an offset of 0 by asking the output section whether it is tail merge.
Differential Revision: http://reviews.llvm.org/D19953
llvm-svn: 268604
MIPS N64 ABI introduces .MIPS.options section which specifies miscellaneous
options to be applied to an object/shared/executable file. LLVM as well as
modern versions of GNU tools read and write the only type of the options -
ODK_REGINFO. It is exact copy of .reginfo section used by O32 ABI.
llvm-svn: 268485
This change simplifies the BuildId classes by removing a few member
functions and variables from them. It should also make it easy to
parallelize hash computation in future because now each BuildId object
see all inputs rather than one at a time.
llvm-svn: 268333
This reverts commit r266618. It breaks basically everything.
I think VS2013 doesn't interpret this code in the same way.
The size field (at least) is left uninitialized, causing all sorts of havok
(e.g. creating a 34GB file for a trivial hello world program).
The offending compiler reports itself as follows:
c:\release-vs2013>cl /?
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
llvm-svn: 266857
With this patch we use the first scan over the relocations to remember
the information we found about them: will them be relaxed, will a plt be
used, etc.
With that the actual relocation application becomes much simpler. That
is particularly true for the interfaces in Target.h.
This unfortunately means that we now do two passes over relocations for
non SHF_ALLOC sections. I think this can be solved by factoring out the
code that scans a single relocation. It can then be used both as a scan
that record info and for a dedicated direct relocation of non SHF_ALLOC
sections.
I also think it is possible to reduce the number of enum values by
representing a target with just an OutputSection and an offset (which
can be from the start or end).
This should unblock adding features like relocation optimizations.
llvm-svn: 266158
Previously, we supported only one hash function, FNV-1, so
BuildIdSection directly handled hash computation. In this patch,
I made BuildIdSection an abstract class and defined two subclasses,
BuildIdFnv1 and BuildIdMd5.
llvm-svn: 265737
This requires knowing input section offsets in output sections before
scanRelocs. This is generally a good thing and should allow further
simplifications in the creation of dynamic relocations.
llvm-svn: 265673
Some targets might require creation of thunks. For example, MIPS targets
require stubs to call PIC code from non-PIC one. The patch implements
infrastructure for thunk code creation and provides support for MIPS
LA25 stubs. Any MIPS PIC code function is invoked with its address
in register $t9. So if we have a branch instruction from non-PIC code
to the PIC one we cannot make the jump directly and need to create a small
stub to save the target function address.
See page 3-38 ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
- In relocation scanning phase we ask target about thunk creation necessity
by calling `TagetInfo::needsThunk` method. The `InputSection` class
maintains list of Symbols requires thunk creation.
- Reassigning offsets performed for each input sections after relocation
scanning complete because position of each section might change due
thunk creation.
- The patch introduces new dedicated value for DefinedSynthetic symbols
DefinedSynthetic::SectionEnd. Synthetic symbol with that value always
points to the end of the corresponding output section. That allows to
escape updating synthetic symbols if output sections sizes changes after
relocation scanning due thunk creation.
- In the `InputSection::writeTo` method we write thunks after corresponding
input section. Each thunk is written by calling `TargetInfo::writeThunk` method.
- The patch supports the only type of thunk code for each target. For now,
it is enough.
Differential Revision: http://reviews.llvm.org/D17934
llvm-svn: 265059
Local symbol which requires GOT entry initialized by "page" address.
This address is high 16 bits of sum of the symbol value and the relocation
addend. In the relocation scanning phase final values of symbols are unknown
so to reduce number of allocated GOT entries do the following trick. Save
all output sections referenced by GOT relocations during the relocation
scanning phase. Then later in the `GotSection::finalize` method calculate
number of "pages" required to cover all saved output sections and allocate
appropriate number of GOT entries. We assume the worst case - each 64kb
page of the output section has at least one GOT relocation against it.
Differential Revision: http://reviews.llvm.org/D18349
llvm-svn: 264730
Now local symbols have SymbolBody so we can handle all kind of symbols
in the GotSection::addEntry method. The patch moves the code from
addMipsLocalEntry to addEntry. NFC.
Differential Revision: http://reviews.llvm.org/D18302
llvm-svn: 264032
We want to make SymbolBody the central place to query symbol information.
This patch also renames canBePreempted to isPreemptible because I feel that
the latter is slightly better (the former is three words and the latter
is two words.)
llvm-svn: 263386
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
It was a badly specified hack for when a tls relocation should be
propagated to the dynamic relocation table.
This replaces it with a not as bad hack of saying that a local dynamic
tls relocation is never preempted.
I will try to remove even that second hack in the next patch.
llvm-svn: 262955
There was a known limitation for -r option:
relocations against local symbols were not supported.
For example rel[a].eh_frame sections contained relocations against sections
and that was not supported for -r before. Patch fixes that.
Differential review: http://reviews.llvm.org/D17813
llvm-svn: 262590
For shared libraries we allow any weak undefined symbol to eventually be
resolved, even if we never see a definition in another .so. This matches
the behavior when handling other undefined symbols in a shared library.
For executables, we require seeing a definition in a .so or resolve it
to zero. This is also similar to how non weak symbols are handled.
llvm-svn: 262017
-r, -relocatable - Generate relocatable output
Currently does not have support for files containing
relocation sections with entries that refer to local
symbols (like rel[a].eh_frame which refer to sections
and not to symbols)
Differential revision: http://reviews.llvm.org/D14382
llvm-svn: 261838
There is nothing aarch64 specific in here. If a symbol can be preempted,
we need to copy the full relocation to the dynamic linker.
If a symbol cannot be preempted, we can make the dynamic linker life
easier and produce a relative relocation.
This is directly equivalent to R_X86_64_64 to R_x86_64_RELATIVE
conversion.
llvm-svn: 261678
This patch fixes the R_AARCH64_ABS64 relocation when used in shared mode,
where it requires a dynamic R_AARCH64_RELATIVE relocation. To correct set
the addend on the dynamic relocation (since it will be used by the dynamic
linker), a new TargetInfo specific hook was created (getDynRelativeAddend)
to get the correct addend based on relocation type.
The patch fixes the issues when creating shared library code against
{init,fini}_array, where it issues R_AARCH64_ABS64 relocation against
local symbols.
llvm-svn: 261651
This reduces the .rodata of scyladb from 4501932 to 4334639 bytes (1.038
times smaller).
I don't think it is critical to support tail merging, just exact
duplicates, but given the code organization it was actually a bit easier
to support both.
llvm-svn: 261327
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
IMHO this makes the code easier to read and should help with linker
scripts.
This is strongly based on D16575. The main differences are:
We record a range of sections, not every section in a program header.
scanHeaders takes case of deciding what goes in every program header,
including PT_GNU_RELRO
We create dummy sections for the start of the file
With this, program header creation has 3 isolated stages:
Map sections to program headers.
Assign addresses to *sections*
Looking at sections find the address and size of each program header.
Thanks to George Rimar for the initial version.
llvm-svn: 260453
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
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
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
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
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
The number of output sections is usually limited, so the cost
of allocating them is not a bottleneck. This patch simplifies
the code by removing the allocators.
llvm-svn: 256437
OutputSectionBase already has virtual member functions.
This patch makes addSection() a virtual function to remove code
from Writer::createSections().
llvm-svn: 256436
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
MIPS .reginfo section provides information on the registers used by
the code in the object file. Linker should collect this information and
write .reginfo section in the output file. This section contains a union
of used registers masks taken from input .reginfo sections and final
value of the `_gp` symbol.
For details see the "Register Information" section in Chapter 4 in the
following document:
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
The patch implements .reginfo sections handling with a couple missed
features: a) it does not put output .reginfo section into the separate
REGINFO segment; b) it does not merge `ri_cprmask` masks from input
section. These features will be implemented later.
Differential Revision: http://reviews.llvm.org/D15669
llvm-svn: 256119
Main aim of the patch to introduce basic support for TLS access models for x86 target.
Models using @tlsgd, @tlsldm and @gotntpoff are implemented.
Differential revision: http://reviews.llvm.org/D15060
llvm-svn: 254500
Combination of @tlsgd and @gottpoff at the same time leads to miss of R_X86_64_TPOFF64 dynamic relocation. Patch fixes that.
@tlsgd(%rip) - Allocate two contiguous entries in the GOT to hold a tls index
structure (for passing to tls get addr).
@gottpoff(%rip) - Allocate one GOT entry to hold a variable offset in initial TLS
block (relative to TLS block end, %fs:0).
The same situation can be observed for x86 (probably others too, not sure) with corresponding for that target relocations: @tlsgd, @gotntpoff.
Differential revision: http://reviews.llvm.org/D15105
llvm-svn: 254443
Fix was:
uint32_t getLocalTlsIndexVA() { return getVA() + LocalTlsIndexOff; }
=>
uint32_t getLocalTlsIndexVA() { return Base::getVA() + LocalTlsIndexOff; }
Both works for my MSVS.
Original commit message:
[ELF] - Refactor of tls_index implementation for tls local dynamic model.
Patch contains the next 2 changes:
1) static variable Out<ELFT>::LocalModuleTlsIndexOffset moved to Out<ELFT>::Got. At fact there is no meaning for it to be separated from GOT class because at each place of using it anyways needs to call GOT`s getVA(). Also it is impossible to have that offset and not have GOT.
2) addLocalModuleTlsIndex -> addLocalModelTlsIndex (word "Module" changed to "Model"). Not sure was it a mistype or not but I think that update is closer to Urlich terminology.
Differential revision: http://reviews.llvm.org/D15113
llvm-svn: 254433
It failed buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/3782/steps/build/logs/stdio
Target.cpp
In file included from /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/ELF/Target.cpp:20:
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/ELF/OutputSections.h:136:42: error: use of undeclared identifier 'getVA'
uint32_t getLocalTlsIndexVA() { return getVA() + LocalTlsIndexOff; }
llvm-svn: 254432
Patch contains the next 2 changes:
1) static variable Out<ELFT>::LocalModuleTlsIndexOffset moved to Out<ELFT>::Got. At fact there is no meaning for it to be separated from GOT class because at each place of using it anyways needs to call GOT`s getVA(). Also it is impossible to have that offset and not have GOT.
2) addLocalModuleTlsIndex -> addLocalModelTlsIndex (word "Module" changed to "Model"). Not sure was it a mistype or not but I think that update is closer to Urlich terminology.
Differential revision: http://reviews.llvm.org/D15113
llvm-svn: 254428
Splitted writeTo to separate tls relocs handling stuff which is too long for one method now. NFC.
Differential revision: http://reviews.llvm.org/D15012
llvm-svn: 254309
Patch implements lazy relocations for x86.
One of features of x86 is that executable files and shared object files have separate procedure linkage tables. So patch implements both cases.
Detailed information about instructions used can be found in http://docs.oracle.com/cd/E19620-01/805-3050/chapter6-1235/index.html (search: x86: Procedure Linkage Table).
Differential revision: http://reviews.llvm.org/D14955
llvm-svn: 254098
The MIPS target requires specific dynamic section entries to be defined.
* DT_MIPS_RLD_VERSION and DT_MIPS_FLAGS store predefined values.
* DT_MIPS_BASE_ADDRESS holds base VA.
* DT_MIPS_LOCAL_GOTNO holds the number of local GOT entries.
* DT_MIPS_SYMTABNO holds the number of .dynsym entries.
* DT_MIPS_GOTSYM holds the index of the .dynsym entry
which corresponds to the first entry of the global part of GOT.
* DT_MIPS_RLD_MAP holds the address of the reserved space in the data segment.
* DT_MIPS_PLTGOT points to the .got.plt section if it exists.
* DT_PLTGOT holds the address of the GOT section.
See "Dynamic Section" in Chapter 5 in the following document for detailed
description: ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
Differential revision: http://reviews.llvm.org/D14450
llvm-svn: 252857
This adds support for:
* Uniquing CIEs
* Dropping FDEs that point to dropped sections
It drops 657 488 bytes from the .eh_frame of a Release+Asserts clang.
The link time impact is smallish. Linking clang with a Release+Asserts
lld goes from 0.488064805 seconds to 0.504763060 seconds (1.034 X slower).
llvm-svn: 252790
Peter Collingbourne