The TinyPtrVector of const Thunk<ELFT>* in InputSections.h can cause 
build failures on certain compiler/library combinations when Thunk<ELFT> 
is not a complete type or is an abstract class. Fixed by making Thunk<ELFT>
non Abstract.

type or is an abstract class 

llvm-svn: 274863

This seems to be causing a buildbot failure on lld-x86_64-freebsd. Will
reproduce locally and fix. 

llvm-svn: 274841

    
    Generalise the Mips LA25 Thunk code and implement ARM and Thumb
    interworking Thunks.
    
    - Introduce a new module Thunks.cpp to store the Target Specific Thunk
      implementations.
    - DefinedRegular and Shared have a ThunkData field to record Thunk.
    - A Target can have more than one type of Thunk.
    - Support PC-relative calls to Thunks.
    - Support Thunks to PLT entries.
    - Existing Mips LA25 Thunk code integrated.
    - Support for ARMv7A interworking Thunks.
    
    Limitations:
    - Only one Thunk per SymbolBody, this is sufficient for all currently
      implemented Thunks.
    - ARM thunks assume presence of V6T2 MOVT and MOVW instructions.

    Differential revision: http://reviews.llvm.org/D21891

llvm-svn: 274836

The patch adds one more partition to the MIPS GOT. This time it is for
TLS related GOT entries. Such entries are located after 'local' and 'global'
ones. We cannot get a final offset for these entries at the time of
creation because we do not know size of 'local' and 'global' partitions.
So we have to adjust the offset later using `getMipsTlsOffset()` method.

All MIPS TLS relocations which need GOT entries operates MIPS style GOT
offset - 'offset from the GOT's beginning' - MipsGPOffset constant. That
is why I add new types of relocation expressions.

One more difference from othe ABIs is that the MIPS ABI does not support
any TLS relocation relaxations. I decided to make a separate function
`handleMipsTlsRelocation` and put MIPS TLS relocation handling code
there. It is similar to `handleTlsRelocation` routine and duplicates its
code. But it allows to make the code cleaner and prevent pollution of
the `handleTlsRelocation` by MIPS 'if' statements.

Differential Revision: http://reviews.llvm.org/D21606

llvm-svn: 273569

Peter Smith found while trying to support thunk creation for ARM that
LLD sometimes creates broken thunks for MIPS. The cause of the bug is
that we assign file offsets to input sections too early. We need to
create all sections and then assign section offsets because appending
thunks changes file offsets for all following sections.

This patch separates the pass to assign file offsets from thunk
creation pass. This effectively reverts r265673.

Differential Revision: http://reviews.llvm.org/D21598

llvm-svn: 273532

Previously, relocations for MIPS were scanned twice; once in regular
scanRelocs() and the other is in scanRelocsForThunks. In the former
function, we computed types of relocations and skipped R_THUNK relocations.
In the latter function, we computed the same value again and skipped
all but R_THUNK relocations. It was wasteful. This patch fixes that.
Now R_THUNK relocations are handled in the regular manner.

llvm-svn: 273346

llvm-svn: 273156

llvm-svn: 273140

There are two motivations for this patch. The first one is a preparation
for support MIPS TLS relocations. It might sound like a joke but for GOT
entries related to TLS relocations MIPS ABI uses almost regular approach
with creation of dynamic relocations for each GOT enty etc. But we need
to separate these 'regular' TLS related entries from MIPS specific local
and global parts of GOT. ABI declare simple solution - all TLS related
entries allocated at the end of GOT after local/global parts. The second
motivation it to support GOT relocations for non-preemptible symbols
with addends. If we have more than one GOT relocations against symbol S
with different addends we need to create GOT entries for each unique
Symbol/Addend pairs.

So we store all MIPS GOT entries in separate containers. For non-preemptible
symbols we have to maintain two data structures. The first one is MipsLocal
vector. Each entry corresponds to the GOT entry from the 'local' part
of the GOT contains the symbol's address plus addend. The second one
is MipsLocalMap. It is a map from Symbol/Addend pair to the GOT index.

Differential Revision: http://reviews.llvm.org/D21297

llvm-svn: 273127

llvm-svn: 273006

llvm-svn: 273004

I think it is me who named these variables, but I always find that
they are slightly confusing because align is a verb.
Adding four letters is worth it.

llvm-svn: 272984

Just for consistency with other parts of the code.

llvm-svn: 272390

In isPreemptible routine we interested in R_MIPS_GPREL16 relocation
only. This relocation fits 0xf. So the new mask 0xff is just to conform
the ABI specification.

llvm-svn: 272388

It was reported in PR28020, that lld does not link code which
gold do. But in fact that is expected behavior as we do not
support DT_TEXTREL.

This patch changes error message as it can report about relocations against
text segments exclusively, other dynamic relocations errors can 
be handled separately.

Differential revision: http://reviews.llvm.org/D21133

llvm-svn: 272377

llvm-svn: 272265

If the symbol is local we don't need to create a R_X86_64_DTPOFF64, we
can just write the correct value in the got.

Should fix pr28018.

llvm-svn: 272205

llvm-svn: 272146

llvm-svn: 272134

That made few places in code a bit shorter.

llvm-svn: 272133

llvm-svn: 271815

This remove some EM_386 specific code from InputSection.cpp and opens
the way for more relaxations.

llvm-svn: 271814

It will also be used for GT_TO_IE relaxations.

llvm-svn: 271813

It will be used for more than just gots.

llvm-svn: 271812

We were not handling page relative relocations.

llvm-svn: 271798

This is mostly extracted from http://reviews.llvm.org/D18960.

The general idea for tlsdesc is that the two GD got entries are used
for a function pointer and its argument. The dynamic linker sets
both. In the non-dlopen case the dynamic linker sets the function to
the identity and the argument to the offset in the tls block.

All that the static linker has to do in the non-dlopen case is
relocate the code to point to the got entries and create a dynamic
relocation.

The dlopen case is more complicated, but can be implemented in another patch.

llvm-svn: 271569

Patch implements next relaxation from latest ABI:

"Convert memory operand of test and binop into immediate operand, where binop is one of adc, add, and, cmp, or,
sbb, sub, xor instructions, when position-independent code is disabled."

It is described in System V Application Binary Interface AMD64 Architecture Processor 
Supplement Draft Version 0.99.8 (https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, 
B.2 "B.2 Optimize GOTPCRELX Relocations").

Differential revision: http://reviews.llvm.org/D20793

llvm-svn: 271405

This reverts commit r271365.
Sorry, wrong branch.

llvm-svn: 271366

llvm-svn: 271365

In case of MIPS, GP-relative relocations always resolve to a definition
in a regular input file, ignoring the one-definition rule. Such
relocations are used to setup GP relative offsets in a function's
prologue. So we, for example, should not attempt to create a dynamic
relocation even if the target symbol is preemptible.

Fixes bug 27880.

Differential Revision: http://reviews.llvm.org/D20664

llvm-svn: 271100

llvm-svn: 270847

System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8 
(https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations")
introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX.

That patch implements the next relaxation: 
mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg
and also opens door for implementing all other ones.

Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself.

Differential revision: http://reviews.llvm.org/D15779

llvm-svn: 270705

llvm-svn: 270652

scanReloc and the functions on which scanReloc depends is in total
more than 600 lines of code. Since scanReloc does not depend on Writer,
it is better to move it into a separate file.

Differential Revision: http://reviews.llvm.org/D20554

llvm-svn: 270606