AArch64 TLSDESC for local symbol in shared objects are implemented in a
arch specific manner where the TLSDESC dynamic relocation addend is the
symbol VM inside the TLS block. For instance, with a shared library
created from the code:

--
static __thread int32_t x1;
static __thread int64_t x2;

int32_t foo1 (int32_t x)
{
  x1 += x;
  return x;
}

int64_t foo2 (int64_t x)
{
  x2 += x;
  return x;
}
--

The dynamic relocation should be create as:

Relocations [
  Section (N) .rela.dyn {
    <Address1> R_AARCH64_TLSDESC - 0x0
    <Address2> R_AARCH64_TLSDESC - 0x8
  }
]

Where 0x0 addend in first dynamic relocation is the address of 'x1'
in TLS block and '0x8' is the address of 'x2'.

Checked against test-suite on aarch64-linux-gnu.

llvm-svn: 290099

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

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

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

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

llvm-svn: 289733

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: 289471

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: 289293

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

llvm-svn: 289277

llvm-svn: 289224

llvm-svn: 289217

llvm-svn: 289212

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

The current implementation of the output section data store commands
can only handle integer literals, but it should really handle arbitrary
expressions [1].  This commit fixes that.

[1] https://sourceware.org/binutils/docs-2.27/ld/Output-Section-Data.html#Output-Section-Data

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

llvm-svn: 289152

llvm-svn: 289146

llvm-svn: 289084

The feature is documented as
-----------------------------
The format of the dynamic list is the same as the version node
without scope and node name.  See *note VERSION:: for more
information.
--------------------------------

And indeed qt uses a dynamic list with an 'extern "C++"' in it. With
this patch we support that

The change to gc-sections-shared makes us match bfd. Just because we
kept bar doesn't mean it has to be in the dynamic symbol table.

The changes to invalid-dynamic-list.test and reproduce.s are because
of the new parser.

The changes to version-script.s are the only case where we change
behavior with regards to bfd, but I would like to see a mix of
--version-script and --dynamic-list used in the wild before
complicating the code.

llvm-svn: 289082

llvm-svn: 289081

llvm-svn: 289079

llvm-svn: 289078

This is the last peculiar semantics left in the linker. If you want to
always set an entry point to 0, you can pass `-e 0` to the linker.

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

llvm-svn: 289077