This patch adds Size member to SectionPiece so that getRangeAndSize
can just return a SectionPiece instead of a std::pair<SectionPiece *, uint_t>.
Also renamed the function.
llvm-svn: 270346
We were using std::pair to represents pieces of splittable section
contents. It hurt readability because "first" and "second" are not
meaningful. This patch give them names.
One more thing is that piecewise liveness information is stored to
the second element of the pair as a special value of output section
offset. It was confusing, so I defiend a new bit, "Live", in the
new struct.
llvm-svn: 270340
This makes it explicit that each R_RELAX_TLS_* is equivalent to some
other expression.
With this I think we are at a sweet spot for how much is done in
Target.cpp. I did experiment with moving *all* the value math out of it.
It has the advantage that we know the final value in target independent
code, but it gets quite verbose.
llvm-svn: 270277
Lazy binding is quite important for use case like a shared build of
llvm. Also, if someone wants to disable it, it is better done in the
compiler (disable plt generation).
The only reason to keep it is to make it easier to add a new
architecture. But it doesn't really help much as it is possible to start
with non lazy relocation and plt code but still let the generic part
create a dedicated .got.plt and .rela.plt.
llvm-svn: 269982
New names reflect purpose of corresponding GOT entries better.
Both expression types related to entries allocated in the 'local'
part of MIPS GOT. R_MIPS_GOT_LOCAL_PAGE is for entries contain 'page'
addresses. R_MIPS_GOT_LOCAL is for entries contain 'full' address.
llvm-svn: 269597
If you specify the option in the form of --build-id=0x<hexstring>,
that hexstring is set as a build ID. We observed that the feature
is actually in use in some builds, so we want this feature.
llvm-svn: 269495
The Elf_Rela has an explicit addend. It doesn't need the addend to be
written to the section being relocated.
Since relative relocations are very common in the output, this is a
noticeable speedup. The results I got were
chromium
master 4.778149487
patch 4.761120792 0.996436131802
chromium fast
master 1.896253636
patch 1.840990582 0.970856718241
the gold plugin
master 0.399337811
patch 0.392279276 0.982324401032
clang
master 0.666873675
patch 0.665895708 0.998533504865
llvm-as
master 0.037101095
patch 0.037123149 1.00059442989
the gold plugin fsds
master 0.422473396
patch 0.414192879 0.980399909016
clang fsds
master 0.747302008
patch 0.744843964 0.996710775599
llvm-as fsds
master 0.033146245
patch 0.033064531 0.997534743377
scylla
master 4.08857525
patch 4.082245184 0.998451767275
llvm-svn: 269417
Just do not allow to link shared library if there are
undefined symbols.
This fixes PR27447
Differential revision: http://reviews.llvm.org/D20169
llvm-svn: 269183
This is the option which sorts relocs to optimize dynamic linker performance.
-z combelocs is the default in gold, also it ignores -z nocombreloc,
this patch do the same.
Patch sorts relocations by symbols only and do not create any
DT_REL[A]COUNT entries. That is different with what gold/bfd do.
More information about option is here:
http://www.airs.com/blog/archives/186http://people.redhat.com/jakub/prelink.pdf, p.2
Differential revision: http://reviews.llvm.org/D19528
llvm-svn: 269066
In case of MIPS ABI relocation has R_GOTREL expression's type iif the
relocation type is either R_MIPS_GPREL16 or R_MIPS_GPREL32. So it is
enough to check expression's type only.
llvm-svn: 268741
We were creating the copy relocations just fine, but then thinking that
the .bss position could be preempted and creating a dynamic relocation
to it, which would crash at runtime since that memory is read only.
llvm-svn: 268668
This allows the combined LTO object to provide a definition with the same
name as a symbol that was internalized without causing a duplicate symbol
error. This normally happens during parallel codegen which externalizes
originally-internal symbols, for example.
In order to make this work, I needed to relax the undefined symbol error to
only report an error for symbols that are used in regular objects.
Differential Revision: http://reviews.llvm.org/D19954
llvm-svn: 268649
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
We were already checking for non relative relocations.
If we ever decide to add support for rw text segments this means we will
have a single spot to add the flag.
llvm-svn: 268558
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
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 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 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
These would just crash at runtime.
If we ever decide to support rw text segments this should make it easier
to implement as there is now a single point where we notice the problem.
I have tested this with a freebsd buildworld. It found a non pic
assembly file being linked into a .so,. With that fixed, buildworld
finished.
llvm-svn: 268149
Relocations against sections with no SHF_ALLOC bit are R_ABS relocations.
Currently we are creating Relocations vector for them, but that is wasteful.
This patch is to skip vector construction and to directly apply relocations
in place.
This patch seems to be pretty effective for large executables with debug info.
r266158 (Rafael's patch to change the way how we apply relocations) caused a
temporary performance degradation for such executables, but this patch makes
it even faster than before.
Time to link clang with debug info (output size is 1070 MB):
before r266158: 15.312 seconds (0%)
r266158: 17.301 seconds (+13.0%)
Head: 16.484 seconds (+7.7%)
w/patch: 13.166 seconds (-14.0%)
Differential Revision: http://reviews.llvm.org/D19645
llvm-svn: 267917
It is now used only for relocations that only set the low bits inside a
page. Everything else is handled by getRelExpr.
I will send a another review renaming and better documenting
isRelRelative.
llvm-svn: 267705
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 remove a fixme, cleans up the weak undef interaction with archives and
lets us keep weak undefs still weak if they resolve to shared.
llvm-svn: 267555
The fix is to handle local symbols referring to SHF_MERGE sections.
Original message:
GC entries of SHF_MERGE sections.
It is a fairly direct extension of the gc algorithm. For merge sections
instead of remembering just a live bit, we remember which offsets
were used.
This reduces the .rodata sections in chromium from 9648861 to 9477472
bytes.
llvm-svn: 267233
These are properties of a symbol name, rather than a particular instance
of a symbol in an object file. We can simplify the code by collecting these
properties in Symbol.
The MustBeInDynSym flag has been renamed ExportDynamic, as its semantics
have been changed to be the same as those of --dynamic-list and
--export-dynamic-symbol, which do not cause hidden symbols to be exported.
Differential Revision: http://reviews.llvm.org/D19400
llvm-svn: 267183
I noticed that I was looking for the definition of SymPair when hacking
the Writer, only to find that it is just a pair of DefinedRegular symbols.
I don't think it provides more values than the cost of using brainpower
to memorize the type. I didn't roll back r266317, which introduced SymPair,
because the patch removes code repetitions. I ported that change to new
code.
llvm-svn: 267047
MIPS ABI turns using of GOT and dynamic relocations inside out. While
regular ABI uses dynamic relocations to fill up GOT entries MIPS ABI
requires dynamic linker to fills up GOT entries using specially sorted
dynamic symbol table. This affects even dynamic relocations against
symbols which do not require GOT entries creation explicitly, i.e. do
not have any GOT-relocations. So if a preemptible symbol has a dynamic
relocation we anyway have to create a GOT entry for it.
If a non-preemptible symbol has a dynamic relocation against it, dynamic
linker takes it st_value, adds offset and writes down result of the
dynamic relocation. In case of preemptible symbol dynamic linker
performs symbol resolution, writes the symbol value to the GOT entry and
reads the GOT entry when it needs to perform a dynamic relocation.
Differential Revision: http://reviews.llvm.org/D18948
llvm-svn: 266921
Originally, linker scripts were basically an alternative way to specify
options to the command line options. But as we add more features to hanlde
symbols and sections, many member functions needed to be templated.
Now most the members are templated. It is probably time to template the
entire class.
Previously, LinkerScript is an executor of the linker script as well as
a storage of linker script configurations. This is not suitable to template
the class because when we are reading linker script files, we don't know
the ELF type yet, so we can't instantiate ELF-templated classes.
In this patch, I defined a new class, ScriptConfiguration, to store
linker script configurations. ScriptParser writes parse results to it,
and LinkerScript uses them.
Differential Revision: http://reviews.llvm.org/D19302
llvm-svn: 266908
It is now redundant. Writer.cpp can reason that 2 dynamic relocations
are needed: one to find the final got entry address and one to fill the
got entry.
llvm-svn: 266876
This requires adding a few more expression types, but is already a small
simplification. Having Writer.cpp know the exact expression will also
allow further simplifications.
llvm-svn: 266604
* Do script driven layout only if SECTIONS section exist.
Initial commit message:
[ELF] - Implemented basic location counter support.
This patch implements location counter support.
It also separates assign addresses for sections to assignAddressesScript() if it scipt exists.
Main testcase is test/ELF/linkerscript-locationcounter.s, It contains some work with location counter. It is basic now.
Implemented location counter assignment and '+' operations.
Patch by myself with LOTS of comments and design suggestions from Rui Ueyama.
Differential revision: http://reviews.llvm.org/D18499
llvm-svn: 266526
This patch implements location counter support.
It also separates assign addresses for sections to assignAddressesScript() if it scipt exists.
Main testcase is test/ELF/linkerscript-locationcounter.s, It contains some work with location counter. It is basic now.
Implemented location counter assignment and '+' operations.
Patch by myself with LOTS of comments and design suggestions from Rui Ueyama.
Differential revision: http://reviews.llvm.org/D18499
llvm-svn: 266457
The _gp_disp symbol designates offset between start of function and 'gp'
pointer into GOT. The following code is a typical MIPS function preamble
used to setup $gp register:
lui $gp, %hi(_gp_disp)
addi $gp, $gp, %lo(_gp_disp)
To calculate R_MIPS_HI16 / R_MIPS_LO16 relocations results we use
the following formulas:
%hi(_gp - P + A)
%lo(_gp - P + A + 4),
where _gp is a value of _gp symbol, A is addend, and P current address.
The R_MIPS_LO16 relocation references _gp_disp symbol is always the second
instruction. That is why we need four byte adjustments. The patch assigns
R_PC type for R_MIPS_LO16 relocation and adjusts its addend by 4. That fix
R_MIPS_LO16 calculation.
For details see p. 4-19 at ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
Differential Revision: http://reviews.llvm.org/D19115
llvm-svn: 266368
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
That was removed in r266304, but leads to warnings by Clang.
Thanks to Rafael Espíndola for pointing on that.
Though I think change was legal from point of C++.
llvm-svn: 266306
They are unnecessary, as the dynamic loader can apply the original relocations
directly. This was also resulting in the creation of copy relocations in PIEs.
Differential Revision: http://reviews.llvm.org/D19089
llvm-svn: 266273
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
We need to ensure that the address of an undefined weak symbol evaluates to
zero. We were getting this right for non-PIC executables (where the symbol
can be evaluated directly) and for DSOs (where we emit a symbolic relocation
for these symbols, as they are preemptible). But we weren't getting it right
for PIEs. Probably the simplest way to ensure that these symbols evaluate
to zero is by not creating a relocation in .got for them.
Differential Revision: http://reviews.llvm.org/D19044
llvm-svn: 266161
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
The _gp* family of symbols is defined as an offset in .got, and it is
not at all clear what should happen when .got is not defined.
This will allow some simplifications on how these symbols are handled.
llvm-svn: 266063
It is possible that the same symbol referenced by two kinds of
relocations at the same time. The first type requires say GOT entry
creation, the second type requires dynamic copy relocation. For MIPS
targets they might be R_MIPS_GOT16 and R_MIPS_HI16 relocations. For X86
target they might be R_386_GOT32 and R_386_32 respectively.
Now LLD never creates GOT entry for a symbol if this symbol already has
related copy relocation. This patch solves this problem.
Differential Revision: http://reviews.llvm.org/D18862
llvm-svn: 265910
Now MustBeInDynSym is only true if the symbol really must be in the
dynamic symbol table.
IsUsedInRegularObj is only true if the symbol is used in a .o or -u. Not
a .so or a .bc.
A benefit is that this is now done almost entirilly during symbol
resolution. The only exception is copy relocations because of aliases.
This includes a small fix in that protected symbols in .so don't force
executable symbols to be exported.
This also opens the way for implementing internalize for -shared.
llvm-svn: 265826
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
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
ELF and program header are not part of OutputSections list anymore.
That helps to avoid having and working with functions like dummySectionsNum().
Still keeping them as sections helps to simplify the code.
Differential revision: http://reviews.llvm.org/D18743
llvm-svn: 265522
Where Clang's AArch64 backend seems to differ from the X86 backend is
that it tends to use the GOT more aggressively.
After getting CloudABI PIEs working on x86-64, I noticed that accessing
global variables would still crash on aarch64. Tracing it down, it turns
out that the GOT was filled with entries assuming the base address was
zero.
It turns out that we skip generating relocations for GOT entries in case
the relocation pointing towards the GOT is relative. Whether the thing
pointing to the GOT is absolute or relative shouldn't make any
difference; the GOT entry itself should contain the absolute address,
thus needs a relocation regardless.
Approved by: rafael
Differential Revision: http://reviews.llvm.org/D18739
llvm-svn: 265453
For each copy relocation that we create, look through the DSO's symbol table
for aliases and create a dynamic symbol for each one. This causes the copy
relocation to correctly interpose any aliases.
Copy relocations are relatively uncommon (on my machine, 56% of binaries in
/usr/bin have no copy relocations probably due to being PIEs, 97% of them
have <10, and the binary with the largest number of them has 97) so it's
probably fine to do this in a relatively inefficient way.
Differential Revision: http://reviews.llvm.org/D18731
llvm-svn: 265354
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
Extracts code for initializing dummies sections
to avoid possible duplication in following patches.
Differential review: http://reviews.llvm.org/D18691
llvm-svn: 265159
Some functions in Writer reports error using HasError, and some reports
their return values. This patch makes them to consistently use HasError.
llvm-svn: 265156
fixAbsoluteSymbols fixes linker-created symbol addresses. Since we don't
create such symbols for relocatable output, we don't need to call this
function.
llvm-svn: 265154
assignAddressesRelocatable function did not set addresses to sections
despite its name. What it actually did is to set file offsets to sections.
assignAddresses function assigned addresses and file offsets to sections.
So there was a confusion what they were doing, and they had duplicate code.
This patch separates file offset assignments from address assignments.
A new function, assignFileOffsets assign file offsets. assignAddresses
do not care about file offsets anymore.
llvm-svn: 265151
The extra fix is to note that it still requires copy relocations.
Original message:
Change how we handle R_MIPS_LO16.
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
P.S.: Suggestions for a better name for the predicate are welcome :-)
llvm-svn: 265150
That is consistent with other symbols: _edata, _etext
and can help to avoid duplicate code.
Differential revision: http://reviews.llvm.org/D18655
llvm-svn: 265129
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
If we make R_MIPS_LO16 a relative relocation, linker:
- never creates R_MIPS_COPY relocation for it
- attempts to create R_MIPS_REL32 dynamic relocation if R_MIPS_LO16's
target is a preemptible symbol
Differential Revision: http://reviews.llvm.org/D18607
llvm-svn: 264956
gold and bfd do not include the undefined locals in symtab.
We have no reasons to support that either.
That fixes PR27016
Differential revision: http://reviews.llvm.org/D18554
llvm-svn: 264843
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
llvm-svn: 264761
When a tls access is optimized, a group of relocations is converted at a
time.
We were already skipping relocations that were optimized out in
relocate, but not in scanRelocs.
This is a small optimization. I got here while working on a patch that
will always keep scanRelocs and relocate in sync.
llvm-svn: 264048
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
-pie
--pic-executable
Create a position independent executable. This is currently only
supported on ELF platforms. Position independent executables are
similar to shared libraries in that they are relocated by the
dynamic linker to the virtual address the OS chooses for them
(which can vary between invocations). Like normal dynamically
linked executables they can be executed and symbols defined in the
executable cannot be overridden by shared libraries.
Differential revision: http://reviews.llvm.org/D18183
llvm-svn: 263693
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
error returned true if there was an error. This allows us to replace
the code like this
if (EC) {
error(EC, "something failed");
return;
}
with
if (error(EC, "something failed"))
return;
I thought that that was a good idea, but it turned out that we only
have two places to use this pattern. So this patch removes that feature.
llvm-svn: 263362
At least Linux has the kernel configuration to include the first page
of the executable into core files. We want build ID section to be
included in core files to identify them.
Here is the link to the description about the kernel configuration.
097f70b3c4/fs/Kconfig.binfmt (L46)
llvm-svn: 263351
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 discussed to make all messages be
lowercase to be consistent with clang.
(also reverts the r263128 which fixed
build bot fail after r263125)
Original commit message:
[ELF] - Consistent spelling for error/warning messages
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263240
We can argue about a maximum alignment of a group of symbols,
but for each symbol, there is only one alignment.
So it is a bit weird that each symbol has a "maximum alignment".
llvm-svn: 263151
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263125
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
The variables corresponding to command line options are named mechanically.
Because the option for the variable is -noinhibit-exec and not -no-inhibit-exec,
it should be name this way.
llvm-svn: 262911
Get rid of few accessors in that class, and replace
them with direct fields access.
Differential revision: http://reviews.llvm.org/D17879
llvm-svn: 262796
Patch changes all relocations types to be uint32_t and also
fixes some dependent inconsistency in callers code.
Differential revision: http://reviews.llvm.org/D17882
llvm-svn: 262793
The rules for when we can relax tls relocations are target independent.
The only things that are target dependent are the relocation values.
llvm-svn: 262748
SymbolBody constructor and friends take isFunc and isTLS boolean arguments.
ELF symbols have already a type so than be easily passed as argument.
If we want to support another type, this scheme is not good enough, that is,
the current code logic would require passing another `bool isObject` around.
Up to two argument, this stretching exercise was a little bit goofy but
still acceptable, but with more types to support, is just too much, IMHO.
Change the code so that the type is passed instead.
Differential Revision: http://reviews.llvm.org/D17871
llvm-svn: 262684
When generating relocatable output SHT_NOBITS sections
were still occupy the file space.
Differential revision: http://reviews.llvm.org/D17857
llvm-svn: 262650
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
As was suggested in mails, this patch implements edata/etext
symbols in a more direct way.
It iterates through PT_LOADs.
Result seems to be the same and equal to gold output.
Differential revision: http://reviews.llvm.org/D17755
llvm-svn: 262369
__start_/__end_ <section-name> symbols and other specials like:
preinit_array_start/end
init_array_start/end
fini_array_start/end
should not be created by linker when creating relocatable files.
Differential revision: http://reviews.llvm.org/D17774
llvm-svn: 262366
Regarding the comment, it is out of context because it describes
what it does not do there. It got too long because it was originally
two different comments that were simply merged together.
The semantics is described in fixAbsoluteSymbols, so we don't need it.
llvm-svn: 262031
https://docs.oracle.com/cd/E53394_01/html/E54766/u-etext-3c.html
It is said that:
_etext - The address of _etext is the first
location after the last read-only loadable segment.
_edata - The address of _edata is the first
location after the last read-write loadable segment.
_end - If the address of _edata is greater than the address
of _etext, the address of _end is same as the address of _edata.
In real life _end and _edata has different values for that case.
Both gold/bfd set _edata to the end of the last non SHT_NOBITS section.
This patch do the same for consistency.
It should fix the https://llvm.org/bugs/show_bug.cgi?id=26729.
Differential revision: http://reviews.llvm.org/D17601
llvm-svn: 262019
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
"Discarded" section is a marker for discarded sections, and we do not
use the instance except for checking its identity. In that sense, it
is just another type of a "null" pointer for InputSectionBase. So,
it doesn't have to be a real instance of InputSectionBase class.
In this patch, we no longer instantiate Discarded section but instead
use -1 as a pointer value. This eliminates a global variable which
needed initialization at startup.
llvm-svn: 261761
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
The .tbss section is in the middle of a PT_LOAD. Whatever treatment we
give to its address we must also give to the offset.
We were ignoring it for address computations, but not for offset.
Fixes pr26712.
llvm-svn: 261667
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
Each rule in SECTIONS commands is something like ".foo *(.baz.*)",
which instructs the linker to collect all sections whose name matches
".baz.*" from all files and put them into .foo section.
Previously, we didn't recognize the wildcard character. This patch
adds that feature.
Performance impact is a bit concerning because a linker script can
contain hundreds of SECTIONS rules, and doing pattern matching against
each rule would be too expensive. We could merge all patterns into
single DFA so that it takes O(n) to the input size. However, it is
probably too much at this moment -- we don't know whether the
performance of pattern matching matters or not. So I chose to
implement the simplest algorithm in this patch. I hope this simple
pattern matcher is sufficient.
llvm-svn: 260745
Previously, we had code for linker scripts in Writer. This patch
separates that as LinkerScript class. The class provides a few
functions to query linker scripts and is also a container of some
linker-script-specific information.
Hopefully, Writer will only implement the default behavior and let
the new class handle gotchas regarding linker scripts.
llvm-svn: 260591
R_X86_64_TPOFF64 is a dynamic relocation,
it should not appear in static relocation processing.
Patch fixes it.
Differential revision: http://reviews.llvm.org/D16880
llvm-svn: 260508
They don't count for the memory or file size, so this is mostly just a
simplification.
The only noticeable difference should be fewer empty program headers.
llvm-svn: 260465
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
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
Previously, it was easy to leave some Out<ELFT> fields uninitialized
because assignments to the fields are mixed with output section
instantiations. In this patch, I separate initializations from assignments
to improve readability.
http://reviews.llvm.org/D16864
llvm-svn: 259899
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
Symbol does not need an entry i the 'global' part of GOT if it cannot be
preempted. So canBePreempted fully satisfies us at least for now.
llvm-svn: 259779
If relocation against symbol requires GOT entry creation and this symbol
is defined in DSO, the GOT entry should be created in the 'global' part
of the GOT even if we link executable file. Also we do not need to create
a dynamic symbol table entry for global symbol corresponding to the
local GOT entry.
llvm-svn: 259778
It can fail to open an output file for various reasons, including
lack of permission, too long filename, or the output file is not
a mmap'able file.
llvm-svn: 259596
Some dynamic table tags like RELSZ and PLTRELSZ depens on result of
finalizing corresponding relocation sections. Therefore we have to
finalize .dynamic section at the end.
Differential Revision: http://reviews.llvm.org/D16799
llvm-svn: 259478
Instead of leave unused fields as is, set them to nullptr.
Currnetly this is NFC, but if you call writeResults more than
once, you should be able to see the difference.
llvm-svn: 259444
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
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
Code for handling TLS relocations was moved out scanRelocs() to new function handleTlsRelocations().
That is because scanRelocs already too large to put more TLS code into it.
Differential revision: http://reviews.llvm.org/D16354
llvm-svn: 258392
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
MIPS ABI has relocations like R_MIPS_JALR which is just a hint for
linker to make some code optimization. Such relocations should not be
handled as a regular ones and lead to say dynamic relocation creation.
The patch introduces new virtual `Target::isHintReloc` method, overrides
it in the `MipsTargetInfo` class and calls it in the `Writer<ELFT>::scanRelocs`
method.
Differential Revision: http://reviews.llvm.org/D16193
llvm-svn: 257798
--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
MIPS _gp_disp designates offset between start of function and gp pointer
into GOT therefore any relocations against it do not require dynamic
relocation.
llvm-svn: 257492
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