Patch continues work started in D24706 and D25821.
in this patch symbol table and constant pool areas were
added to .gdb_index section output.
This one finishes the implementation of --gdb-index functionality in LLD.
Differential revision: https://reviews.llvm.org/D26283
llvm-svn: 289810
Patch continues work started in D24706,
in this patch address area was added to .gdb_index section output.
Differential revision: https://reviews.llvm.org/D25821
llvm-svn: 289790
PR31335 shows that we do that in next case:
SECTIONS { .text 0x2000 : {. = 0x100 ; *(.text) } }
though documentations says that "If . is used inside a section
description however, it refers to the byte offset from the start
of that section, not an absolute address. " looks does not work
as documented in bfd (as mentioned in comments for PR31335).
Until we find out the expected behavior was suggested at least not
to 'crash', what we do after trying to generate huge file.
Differential revision: https://reviews.llvm.org/D27712
llvm-svn: 289782
Profiling revealed that the majority of lld's execution time on Windows was
spent opening and mapping input files. We can reduce this cost significantly
by performing these operations asynchronously.
This change introduces a queue for all operations on input file data. When
we discover that we need to load a file (for example, when we find a lazy
archive for an undefined symbol, or when we read a linker directive to
load a file from disk), the file operation is launched using a future and
the symbol resolution operation is enqueued. This implies another change
to symbol resolution semantics, but it seems to be harmless ("ninja All"
in Chromium still succeeds).
To measure the perf impact of this change I linked Chromium's chrome_child.dll
with both thin and fat archives.
Thin archives:
Before (median of 5 runs): 19.50s
After: 10.93s
Fat archives:
Before: 12.00s
After: 9.90s
On Linux I found that doing this asynchronously had a negative effect on
performance, probably because the cost of mapping a file is small enough that
it becomes outweighed by the cost of managing the futures. So on non-Windows
platforms I use the deferred execution strategy.
Differential Revision: https://reviews.llvm.org/D27768
llvm-svn: 289760
`SC` didn't make much sense. We don't seem to have a clear convention,
but `IS` sounds good here because it emphasizes that it is an input
section (this is one place in the code where we are dealing with both
input sections and output sections at the same time so that extra
emphasis makes it a bit clearer).
llvm-svn: 289748
Remove the includes of <llvm/Config/config.h> private LLVM header.
The relevant files seem not to use any definitions from that file,
and it is not available when building against installed LLVM.
The use in lib/ReaderWriter/MachO/MachOLinkingContext.cpp originates
from rL218718, and the use in ELF/Strings.cpp from rL274804 (where it
was moved from Symbols.cpp). In both cases, they were added as a part of
demangling support, and they provided HAVE_CXXABI_H.
Since we are now using the LLVM demangler library instead, the code was
removed and the includes and no longer necessary.
Differential Revision: https://reviews.llvm.org/D27757
llvm-svn: 289707
The eglibc library, as used by Ubuntu 14.04 requires the presence of an
SHT_ARM_ATTRIBUTES section in for the purposes of checking hard/soft float
compatibility when dlopen() is used. Unfortunately when the section is not
present dlopen() fails with a generic could not find file message.
This change makes lld keep the first .ARM.attributes section that it
encounters and propagates it to the output. This is not a complete
SHT_ARM_ATTRIBUTES implementation, that would involve reading the contents
of the section and joining each individual attribute. It should suffice
for a homogenous build all libraries and executables on the same system
with a compatible set of command line options.
Differential revision: https://reviews.llvm.org/D27718
llvm-svn: 289642
When compiling -fpie and linking with the --pie option the R_ARM_GOTBREL
relocation to D is resolved by writing the value of D into the .got slot
and emitting an R_ARM_RELATIVE relocation for it.
This changes adds the R_ARM_RELATIVE relocation to the switch in
relocateOne() so we can process the GotSection relocation to write the
value of the variable as well as emitting the dynamic relocation.
Differential revision: https://reviews.llvm.org/D27678
llvm-svn: 289527
The VA of _gp was being truncated to 32 bits when calling getVa(), but
for 64bit MIPS we need to write a 64 bit value to .MIPS.options.
Patch by Alexander Richardson.
Differential revision: https://reviews.llvm.org/D27672
llvm-svn: 289432
Enable building lld as a standalone project. This is motivated by the desire to
package lld for inclusion in a linux distribution. This allows building lld
against an existing paired llvm installation. Now that lld is usable on x86_64,
it makes sense to revive this configuration to allow distributions to package
it.
llvm-svn: 289421
This patch replaces the symbol table's object and archive queues, as well as
the convergent loop in the linker driver, with a design more similar to the
ELF linker where symbol resolution directly causes input files to be added to
the link, including input files arising from linker directives. Effectively
this removes the last vestiges of the old parallel input file loader.
Differential Revision: https://reviews.llvm.org/D27660
llvm-svn: 289409
Using a set here caused us to take about 1 second longer to write the symbol
table when linking chrome_child.dll. With this I consistently get better
performance on Windows with the new symbol table.
Before r289280 and with r289183 reverted (median of 5 runs): 17.65s
After this change: 17.33s
On Linux things look even better:
Before: 10.700480444s
After: 5.735681610s
Differential Revision: https://reviews.llvm.org/D27648
llvm-svn: 289408
We first decide that the symbol is global, than that it should have
version foo. Since it was already not the default version, we were
producing a bogus warning.
llvm-svn: 289284
This ports the ELF linker's symbol table design, introduced in r268178,
to the COFF linker.
Differential Revision: http://reviews.llvm.org/D21166
llvm-svn: 289280
The former option bases the filename on the output name, e.g. if the
link output is a.exe, the map will be written to a.map. This matches the
behaviour of link.exe's /MAP option and is useful for creating a map
file of each executable when building a large project.
Differential Revision: https://reviews.llvm.org/D27595
llvm-svn: 289271
Profiling revealed that we were spending 5% of our time linking
chrome_child.dll just in this call to toString().
Differential Revision: https://reviews.llvm.org/D27628
llvm-svn: 289270
The i386 glibc ld.so expects the .got.slot entry that is relocated by a
R_386_IRELATIVE relocation to point directly at the ifunc resolver and
not the address of the PLT entry + 6 (thus entering the lazy resolver).
This is also the case for ARM and I suspect it is because these use REL
relocations and can't use the addend field to store the address of the
ifunc resolver. If the lazy resolver is used we get an error message
stating that only R_386_JUMP_SLOT is supported.
As ARM and i386 share the same code, I've removed the ARM specific test
and added a writeIgotPlt() function that by default calls writeGotPlt().
ARM and i386 override this to write the address of the ifunc resolver.
Differential Revision: https://reviews.llvm.org/D27581
llvm-svn: 289198
I don't think the data I add to a TPI stream in this patch is correct,
but at least it can be displayed using llvm-pdbdump. Until I add more
streams to a PDB file, I'm not able to know whether the data will be
accepted by MSVC tools or not.
llvm-svn: 289183
linkerscript.s is the first test file for linker script, and at the moment
it contains all tests for linker scripts. Now that test file doesn't make
sense.
linkerscript2.s was just badly named. Renamed searchdir.s.
llvm-svn: 289148
George Rimar