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
MIPS N64 ABI packs multiple relocations into the single relocation
record. In general, all up to three relocations can have arbitrary types.
In fact, Clang and GCC uses only a few combinations. For now, we support
two of them. That is allow to pass at least all LLVM test suite cases.
<any relocation> / R_MIPS_SUB / R_MIPS_HI16 | R_MIPS_LO16
<any relocation> / R_MIPS_64 / R_MIPS_NONE
The first relocation is a 'real' relocation which is calculated using
the corresponding symbol's value. The second and the third relocations
used to modify result of the first one: extend it to 64-bit, extract
high or low part etc. For details, see part 2.9 'Relocation' at
https://dmz-portal.mips.com/mw/images/8/82/007-4658-001.pdf
llvm-svn: 268876
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
It is insanely hard to write a test that works both on Windows and Unix.
I tried to workaround it with cpio's minor options, but the behaviors of
the options were myterious. It just doesn't worth to spend time on it.
And probably minor options could break buildbots that doesn't have the
GNU version of cpio command.
In this patch, I simply added a separate test file that runs only on
Windows.
llvm-svn: 268596
MIPS N64 ABI packs multiple relocations into the single relocation
record. Particularly it requires to represent dynamic relative
relocation as a combination of R_MIPS_REL32 and R_MIPS_64 relocations.
llvm-svn: 268565
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
Currently we don't check when creating relative relocations if the
section is read only or not. I am about to fix that, so first update the
patches that depend on the current behavior.
llvm-svn: 268542
These relocations introduced by MIPS N64 ABI. R_MIPS_GOT_DISP references
GOT entry with full symbol's address, R_MIPS_GOT_PAGE creates GOT entry
with address of memory page which includes symbol's address,
R_MIPS_GOT_OFST used together with R_MIPS_GOT_PAGE. This relocation
calculates offset from beginning of memory page to the symbol address.
llvm-svn: 268525
As requested by Rafael Espindola in his post-commit comments on r268036. This
makes the previous behaviour the default while still allowing verification of
IAS.
llvm-svn: 268496
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
Both bfd and gold have this. It allows disabling build-id when it is the
default with by adding -Wl,--build-id=none no the clang command line.
llvm-svn: 268435
Introduce a special symbol type to indicate that we have not yet seen a type
for the symbol, so we should not report TLS mismatches for that symbol.
Differential Revision: http://reviews.llvm.org/D19836
llvm-svn: 268411
We want --reproduce to
* not rewrite scripts and thin archives
* work with absolute paths
Given that, it pretty much has to create a full directory tree. On windows that
is problematic because of the very short maximum path limit. On most cases
users can still work around it with "--repro c:\r", but that is annoying and
not viable for automated testing.
We then need to produce some form of archive with the files. The first option
that comes to mind is .a files since we already have code for writing them.
There are a few problems with them
The format has a dedicated string table, so we cannot start writing it until
all members are known.
Regular implementations don't support creating directories. We could make
llvm-ar support that, but that is probably not a good idea.
The next natural option would be tar. The problem is that to support long path
names (which is how this started) it needs a "pax extended header" making this
an annoying format to write.
The next option I looked at seems a natural fit: cpio files.
They are available on pretty much every unix, support directories and long path
names and are really easy to write. The only slightly annoying part is a
terminator, but at least gnu cpio only prints a warning if it is missing, which
is handy for crashes. This patch still makes an effort to always create it.
llvm-svn: 268404
The test is now unexpectedly passing on
llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast which is treated as an error.
For now, disable Windows testing of the feature.
Rafael is working on generating an archive, which will hopefully allow
us to turn this test back on.
Unfortunately, we don't have a way to temporarily XFAIL this test just
on llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast.
llvm-svn: 268351
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
`REQUIRES: shell` is not appropriate because that would mean that there
are no windows bots testing this, and that is precisely where it needs
the most testing.
Rafael or Rui are working on generating an archive directly, which
should avoid this issue.
We can try to move the bot to a shorter build directory path.
llvm-svn: 268345
This patch increases the size of Undefined by the size of a pointer,
but it wouldn't actually increase the size of memory that LLD uses
because we are not allocating the exact size but the size of the
largest SymbolBody.
llvm-svn: 268310
With this it is possible to use chroot/fakechroot to have a completely
reproducible link even when thin archives or linker scripts have
absolute paths.
llvm-svn: 268231
Patch implements one of suggestions from Rafael Ávila de Espíndola,
to fix segfault after section that contains personality being
garbage collected.
Suggestion was just to keep alive all non executable sections
referenced by .eh_frame.
This fixes PR27529.
Differential revision: http://reviews.llvm.org/D19656
llvm-svn: 268228
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
The aim of this patch is to make it easy to re-run the command without
updating paths in the command line. Here is a use case.
Assume that Alice is having an issue with lld and is reporting the issue
to developer Bob. Alice's current directly is /home/alice/work and her
command line is "ld.lld -o foo foo.o ../bar.o". She adds "--reproduce repro"
to the command line and re-run. Then the following text will be produced as
response.txt (notice that the paths are rewritten so that they are
relative to /home/alice/work/repro.)
-o home/alice/work/foo home/alice/work/foo.o home/alice/bar.o
The command also produces the following files by copying inputs.
/home/alice/repro/home/alice/work/foo.o
/home/alice/repro/home/alice/bar.o
Alice zips the directory and send it to Bob. Bob get an archive from Alice
and extract it to his home directory as /home/bob/repro. Now his directory
have the following files.
/home/bob/repro/response.txt
/home/bob/repro/home/alice/work/foo.o
/home/bob/repro/home/alice/bar.o
Bob then re-run the command with these files by the following commands.
cd /home/bob/repro
ld.lld @response.txt
This command will run the linker with the same command line options and
the same input files as Alice's, so it is very likely that Bob will see
the same issue as Alice saw.
Differential Revision: http://reviews.llvm.org/D19737
llvm-svn: 268169
Davide Italiano