When the target of the TlsOffsetRel is non-preemptible we can write the
offset directly into the GOT without needing a dynamic relocation. This
is optional for dynamically linked executables but is required for static
linking.
    
This change adds the relocation to the GOT entry and a test case for
non-0 offsets so that if we miss out the offset the test won't spuriously
pass by virtue of the default value being 0.

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

llvm-svn: 299751

    
The handleNoRelaxTlsRelocation handled both ARM and Mips as at a
high-level the actions of what to do when encountering a local dynamic or
global dynamic TLS relocation are the same. However due to Mips using a
custom GOT the differences of the implementation are enough that the
function became difficult to understand.
    
This change replaces handleNotRelaxTlsRelocation into
handleARMTlsRelocation() and handleMipsTlsRelocation() so that the ARM and
Mips specific code is isolated.

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

llvm-svn: 299750

lld-x86_64-darwin13.

llvm-svn: 299749

r299635 exposed a latent bug in the Linux implementation of parallel_for, which
resulted in it calling the function outside of the range requested, resulting
later in a segmentation fault. This change fixes this issue and adds a unit test.

llvm-svn: 299748

The argument was always casted, so cast it in the caller.

llvm-svn: 299742

llvm-svn: 299740

The /appcontainer flag indicates that the module may only be used inside
an application container (for isolation).  This has been supported by
link.exe since Windows 8.0.  It sets an additional bit in the PE DLL
Characteristics flag to indicate the behavioural change.

llvm-svn: 299728

This patch addresses a post-commit review comment for r299615.

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

llvm-svn: 299722

The alignment expression cannot depend on '.', so we can compute it
early.

llvm-svn: 299717

This removes a bit more work from assignAddresses.

llvm-svn: 299716

llvm-svn: 299713

This avoids calling it multiple times. In particular, we don't have to
call in in assignAddresses any more.

llvm-svn: 299709

llvm-svn: 299655

llvm-svn: 299636

Executable sections should not be padded with zero by default. On some
architectures, 0x00 is the start of a valid instruction sequence, so can confuse
disassembly between InputSections (and indeed the start of the next InputSection
in some situations). Further, in the case of misjumps into padding, padding may
start to be executed silently.

On x86, the "0xcc" byte represents the int3 trap instruction. It is a single
byte long so can serve well as padding. This change switches x86 (and x86_64) to
use this value for padding in executable sections, if no linker script directive
overrides it. It also puts the behaviour into place making it easy to change the
behaviour of other targets when desired. I do not know the relevant instruction
sequences for trap instructions on other targets however, so somebody should add
this separately.

Because the old behaviour simply wrote padding in the whole section before
overwriting most of it, this change also modifies the padding algorithm to write
padding only where needed. This in turn has caused a small behaviour change with
regards to what values are written via Fill commands in linker scripts, bringing
it into line with ld.bfd. The fill value is now written starting from the end of
the previous block, which means that it always starts from the first byte of the
fill, whereas the old behaviour meant that the padding sometimes started mid-way
through the fill value. See the test changes for more details.

Reviewed by: ruiu

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

Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32227
llvm-svn: 299635

scanRelocs() does a lot of things. It fills InputSection's Relocations vector,
making a decision whether a TLS relocation should be relaxed or not,
and making a decision whether a GOT/PLT slot needs to be created or not.

They don't actually have to be done in a single loop. I want to separate
them so that some of them can be run concurently. As a first step, this
patch moves PLT/GOT slot assignment to beginning of the loop, so that
they just fall through to the next statements. This should make it clear
that that code doesn't affect other parts of the loop.

llvm-svn: 299615

Relocations are abstracted as platform-independent R_TLS_* relocations,
so we don't need to check platform-specific ones to see if a relocation
is TLS GD.

llvm-svn: 299614

llvm-svn: 299600

llvm-svn: 299594

llvm-svn: 299593

If an output file is too large for 32-bit, we should report an error.

llvm-svn: 299592

llvm-svn: 299590

This class doesn't have virtual member functions, and no instances
of this class is deleted through base pointers.

llvm-svn: 299581

llvm-svn: 299580

llvm-svn: 299579

Symbols referenced by linker scripts are not necessarily be undefined,
so the previous name didn't convey the meaining of the variable.

llvm-svn: 299573

llvm-svn: 299559

Because they are addresses in .got.plt and not in .got.

llvm-svn: 299556

This patch does what r299506 was trying to do in a different way.

llvm-svn: 299554

Previously, the code we set to our .plt entries expected that .got
and .got.plt are consecutive in the virtual address space.
Since %ebx points to the last entry of .got for position-independent
code, it assumed that .got is accessible with small negative
displacements and .got.plt are accessible with small positive
displacements.

That assumption was simply wrong. We don't impose any restrictions on
relative layout of .got and .got.plt. As a result, the control is
transferred to a bogus address from .plt at runtime, which resulted in
segfaults.

This patch removes that wrong assumption. We still assume that .got.plt
has a fixed relative address to .got, but we no longer assume that they
are consecutive in memory.

With this change, a "hello world" program compiled with -fPIC works.

Fixes https://bugs.llvm.org/show_bug.cgi?id=31332.

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

llvm-svn: 299553

    
For range extension thunks we will need to repeatedly call createThunks()
until no more thunks are created. We will need to retain the state of
Thunks that we have created so far to avoid recreating them on later
passes. This change does not change the functionality of createThunks().

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

llvm-svn: 299530

GNU linkers define __bss_start symbol.
Patch teaches LLD to do that. This is PR32051.

Below is part of standart ld.bfd script:

.data1          : { *(.data1) }
  _edata = .; PROVIDE (edata = .);
  . = .;
  __bss_start = .;
  .bss            :
  {
Currently LLD can emit up to 3 .bss* sections as one of testcase shows.
Implementation inserts this symbol before first .bss* output section.

Differential revision: https://reviews.llvm.org/D30419

llvm-svn: 299528

It was not NFC unfortunaly,
one of changes decrements begin() iterator and
that is not allowed by MSVS.

llvm-svn: 299525

llvm-svn: 299521

llvm-svn: 299520

Looks like we can use consume() in many more places.

llvm-svn: 299519

llvm-svn: 299518

This class is used only within this file, so it can be file-local.

llvm-svn: 299516

LinkerScript.cpp contains both the linker script processor and the
linker script parser. I put both into a single file, but the file grown
too large, so it's time to put them into two different files.

llvm-svn: 299515

llvm-svn: 299514