Use of CachedHashStringRef makes sense only when we reuse hash values.
Sprinkling it to all DenseMap has no benefits and just complicates data types.
Basically we shouldn't use CachedHashStringRef unless there is a strong
reason to to do so.

llvm-svn: 290076

I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.

Differential Revision: https://reviews.llvm.org/D27819

llvm-svn: 290062

DWARFDebugPubTable was introduced recently and allows us to get rid of
code duplication in LLD.

llvm-svn: 290042

Differential Revision: https://reviews.llvm.org/D27860

llvm-svn: 290002

Fixes http://llvm.org/PR31129

Patch by Alexander Richardson!

Differential Revision: https://reviews.llvm.org/D27848

llvm-svn: 289968

--sort-section=xxx is the same as --sort-section xxx,
was found in one of FreeBSD ports.

llvm-svn: 289938

File system operations were still dominating the profile on Windows. In this
case we were spending a significant amount of our time repeatedly searching
for libraries as a result of processing linker directives. Address this
by caching whether we have already found a library with a given name. For
chrome_child.dll:

Before: 10.53s
After: 6.88s

Differential Revision: https://reviews.llvm.org/D27840

llvm-svn: 289915

It os used in work/emulators/qemu-user-static port.
Which tries to use -Ttext-segment and then:

# In case ld does not support -Ttext-segment, edit the default linker
# script via sed to set the .text start addr.  This is needed on FreeBSD
# at least.
<here it calls -verbose to extract and edit default bfd linker script.>

Actually now we are do not fully support -Ttext properly (see D27613),
but we also seems never will provide anything close to default script, like bfd do,
so at least this patch introduces proper alias handling.

llvm-svn: 289827

llvm-svn: 289824

llvm-svn: 289823

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

Fixed inaccurate member type: uint32_t -> size_t
(http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/2984/steps/build/logs/stdio).

llvm-svn: 289796

(http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/2982)

llvm-svn: 289792

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

llvm-svn: 289758

`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

llvm-svn: 289745

This name was really confusing because there is also another static
helper Symbols.cpp:getSymVA which has the same name.

llvm-svn: 289733

llvm-svn: 289722

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

llvm-svn: 289550

    
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

llvm-svn: 289499

llvm-svn: 289471

llvm-svn: 289451

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

llvm-svn: 289415

Differential Revision: https://reviews.llvm.org/D27667

llvm-svn: 289414

This resulted in about a 1% perf improvement linking chrome_child.dll.

Differential Revision: https://reviews.llvm.org/D27666

llvm-svn: 289410

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

The existing tbaa metadata in the test is ill-formed, and fails the
verifier after r289402.

llvm-svn: 289405

Adding type records to TPI stream is too time consuming.
It is reported that linking chrome_child.dll took 5 minutes.

llvm-svn: 289330

llvm-svn: 289320

llvm-svn: 289293

llvm-svn: 289289