Fixes pr30282.

llvm-svn: 280709

They were both pointing to the start of the got, not the end.

Fixes pr28924.

llvm-svn: 280310

Not only symbols (like sections) have names, in case where we
fail to create relocation against such symbol, we should not
print out an empty string, instead we should print a generic
message.

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

llvm-svn: 279459

This is fix for PR28976.

Problem was that in scanRelocs, we computed relocation offset too early 
for case when linkerscript was used. Patch fixes the issue 
delaying the calculation.

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

llvm-svn: 279264

We should always include symbol name when reporting relocations
error to simplify debugging of these issues. Without symbol names
users have to manually investigate which of the libraries contain
invalid relocations which can be cumbersome when linking multiple
libraries.

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

llvm-svn: 279162

I wonder what is the most idiomatic way to write this.

llvm-svn: 276338

Had 3 testcases failtures:
ELF/eh-frame-merge.s 
ELF/gc-sections-eh.s
ELF/gc-sections-lsda.s​

Problem was that OutputOff is size_t, which is 32
for this configuration and next
condition never was checked correctly:

if (PieceI->OutputOff == (uintX_t)-1)
  continue;

llvm-svn: 276296

We no longer need it for relocations in .eh_frame.

The only relocations that point to .eh_frame are the ones trying to
find the output .eh_frame.

This actually fixes a bug in the symbol value code. It was not
handling -1 as an indicator for a piece not being included in the
output.

llvm-svn: 276175

llvm-svn: 276157

We will need to do something like this to support range extension
thunks since that process is iterative.

Doing this also has the advantage that when doing the regular
relocation scan the offset in the output section is known and we can
just store that. This reduces the number of times we have to run
getOffset and I think will allow a more specialized .eh_frame
representation.

By itself this is already a performance win.

firefox
  master 7.295045737
  patch  7.209466989 0.98826892235
chromium
  master 4.531254468
  patch  4.509221804 0.995137623774
chromium fast
  master 1.836928973
  patch  1.823805241 0.992855612714
the gold plugin
  master 0.379768791
  patch  0.380043405 1.00072310839
clang
  master 0.642698284
  patch  0.642215663 0.999249070657
llvm-as
  master 0.036665467
  patch  0.036456225 0.994293213284
the gold plugin fsds
  master 0.40395817
  patch  0.404384555 1.0010555177
clang fsds
  master 0.722045545
  patch  0.720946135 0.998477367518
llvm-as fsds
  master 0.03292646
  patch  0.032759965 0.994943428477
scylla
  master 3.427376378
  patch  3.368316181 0.98276810292

llvm-svn: 276146

Thanks to George Rimar for finding the problem.

llvm-svn: 276144

In here we are iterating relocations in order, so we can do the same
with the pieces of .eh_frame and avoid a binary search.

The link times I got with this patch were:

firefox
  master 7.22977811
  patch  7.141041442 0.987726225252
chromium
  master 4.478966851
  patch  4.506602207 1.00617002914
chromium fast
  master 1.894713371
  patch  1.866446889 0.98508139414
the gold plugin
  master 0.386193907
  patch  0.382374918 0.990111213743
clang
  master 0.654849589
  patch  0.647899815 0.989387220949
llvm-as
  master 0.037212718
  patch  0.036858172 0.990472450843
the gold plugin fsds
  master 0.410876711
  patch  0.407418613 0.991583611562
clang fsds
  master 0.734623069
  patch  0.728237526 0.991307728726
llvm-as fsds
  master 0.033446197
  patch  0.03302833 0.987506292569
scylla
  master 3.38134402
  patch  3.414188846 1.00971354166

llvm-svn: 276108

Previously, each subclass of SymbolBody had a pointer to a source
file from which it was created. So, there was no single way to get
a source file for a symbol. We had getSourceFile<ELFT>(), but the
function was a bit inconvenient as it's a template.

This patch makes SymbolBody have a pointer to a source file.
If a symbol is not created from a file, the pointer has a nullptr.

llvm-svn: 275701

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