| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 270326
|
|
|
|
| |
llvm-svn: 270325
|
|
|
|
|
|
|
|
| |
Most functions take destination buffers as the first arguments
just like memcpy, so this order is easier to read.
Also simplified the function.
llvm-svn: 270324
|
|
|
|
| |
llvm-svn: 270281
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
win32 was my case.
Before that change test failed with next error for me:
23> ******************** TEST 'lld :: ELF/mips-64-got.s' FAILED ********************
....
23> Command 3 Stderr:
23> relocation R_MIPS_GOT_PAGE out of range
llvm-svn: 269166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/186
http://people.redhat.com/jakub/prelink.pdf, p.2
Differential revision: http://reviews.llvm.org/D19528
llvm-svn: 269066
|
|
|
|
| |
llvm-svn: 268699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weak undefined.
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
|
|
|
|
| |
llvm-svn: 268133
|
|
|
|
| |
llvm-svn: 268070
|
|
|
|
|
|
|
|
| |
versioned DSOs.
Differential Revision: http://reviews.llvm.org/D19464
llvm-svn: 267775
|
|
|
|
| |
llvm-svn: 267673
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19566
llvm-svn: 267640
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19490
llvm-svn: 267637
|
|
|
|
|
|
| |
Every caller was doing it.
llvm-svn: 267603
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
MIPS is the only target requires GOT header. We already have MIPS
specific code in the `GotSection` class, so move MIPS GOT header
generation there and delete redundant stuff like `GotHeaderEntriesNum`
field and `writeGotHeader` method.
Differential Revision: http://reviews.llvm.org/D19465
llvm-svn: 267460
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r267164.
Revert "Trying to fix the windows build."
This reverts commit r267168.
Debugging a bootstrap problem.
llvm-svn: 267194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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: 267164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that this will read data from the section to properly
handle Elf_Rel implicit addends.
Sorry for the noise.
Original messages:
Try to fix Windows lld build.
Move getRelocTarget to ObjectFile.
It doesn't use anything from the InputSection.
llvm-svn: 267163
|
|
|
|
|
|
| |
It doesn't use anything from the InputSection.
llvm-svn: 267154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NFC."
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
|
|
|
|
|
|
|
| |
This avoids computing the address of a position in the got just to then
subtract got->getva().
llvm-svn: 266831
|
|
|
|
| |
llvm-svn: 266618
|
|
|
|
|
|
| |
It is only ever used on symbols taken from the symbol table.
llvm-svn: 266391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible to have FDEs with duplicate PCs if ICF was able to merge
functions with FDEs, or if the input files for some reason contained duplicate
FDEs. We previously weren't handling this correctly when producing the
contents of the .eh_frame_hdr section; we were dropping entries and leaving
null entries at the end of the section, which confused consumers of unwind
data, such as the backtrace() function.
Fix the bug by setting the FDE count to the number of FDEs actually emitted
into .eh_frame_hdr, rather than the number of FDEs in .eh_frame.
Differential Revision: http://reviews.llvm.org/D18911
llvm-svn: 265957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
The spec says:
If a symbol definition with STV_PROTECTED visibility from a shared
object is taken as resolving a reference from an executable or another
shared object, the SHN_UNDEF symbol table entry created has STV_DEFAULT
visibility.
llvm-svn: 265792
|
|
|
|
| |
llvm-svn: 265791
|
|
|
|
| |
llvm-svn: 265748
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
When the option is specified, then all STB_GNU_UNIQUE symbols are
converted to STB_GLOBAL symbols.
llvm-svn: 265717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
start-lib and end-lib are options to link object files in the same
semantics as archive files. If an object is in start-lib and end-lib,
the object is linked only when the file is needed to resolve
undefined symbols. That means, if an object is in start-lib and end-lib,
it behaves as if it were in an archive file.
In this patch, I introduced a new notion, LazyObjectFile. That is
analogous to Archive file type, but that works for a single object
file instead of for an archive file.
http://reviews.llvm.org/D18814
llvm-svn: 265710
|
|
|
|
|
|
|
| |
The position of a relocation can always be expressed as an offset in an
output section.
llvm-svn: 265682
|
|
|
|
|
|
| |
It is now just a special case of Off_Sec.
llvm-svn: 265676
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
A synthetic symbol can be global or local, and with the current
infrastructure we don't need any special code for it.
Fixes PR27228.
llvm-svn: 265478
|
|
|
|
| |
llvm-svn: 265404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|