We would crash when a non-alloca section pointed to a gced part of a
merge section.

That can happen when a C/c++ constant in put in a merge section and
debug info is present.

llvm-svn: 282845

LLD does not update relocations addends when generate a relocatable
object. That is why we should not write a non-zero GP0 value into
the .reginfo and .MIPS.options sections. And we should not accept input
object files with non-zero GP0 value because we cannot handle them
properly.

llvm-svn: 282716

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

llvm-svn: 282708

If we pass --gc-sections to lld and .tbss is not referenced,
the section is reclaimed and lld doesn't create a TLS program header.
R_TLS tries to access the program header -> lld crashes.
Mimic what bfd/gold do in this case and resolve a weak undefined
TLS symbol to the base of the TLS block, i.e. give it a value of zero.

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

llvm-svn: 282279

r279456 guarantees that this condition is always satisfied.

llvm-svn: 281426

llvm-svn: 281210

This reverts commit r281096.

The previous link errors should be fixed by r281208.

llvm-svn: 281209

This reverts commit r281084.

The link was failing on some bots. No idea why. I will try to
reproduce it on Monday.

llvm-svn: 281096

llvm-svn: 281084

This simplifies error handling as there is now only one place in the
code that needs to consider the possibility that the name is
corrupted. Before we would do it in every access.

llvm-svn: 280937

llvm-svn: 280925

llvm-svn: 280856

Previously we used LayoutInputSection class to correctly assign
symbols defined in linker script. This patch removes it and uses
pointer to preceding input section in SymbolAssignment class instead.

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

llvm-svn: 280348

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

Fixes pr28924.

llvm-svn: 280310

llvm-svn: 280305

llvm-svn: 280237

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

This section supersedes .reginfo and .MIPS.options sections. But for now
we have to support all three sections for ABI transition period.

llvm-svn: 278482

llvm-svn: 278322

llvm-svn: 277566

Previously addends were ignored. This is PR28779.
Patch fixes the issue.

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

llvm-svn: 277432

Since CommonInputSection is a singleton class, we don't need
to store pointers to all DefinedCommon symbols.

llvm-svn: 277410

llvm-svn: 277103

All other singleton instances are accessible globally.
CommonInputSection shouldn't be an exception.

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

llvm-svn: 277034

llvm-svn: 277023

Not all relocations from a .eh_frame that point to an executable
section should be ignored. In particular, the relocation finding the
personality function should not.

This is a reduction from trying to bootstrap a static lld on linux.

llvm-svn: 276329

This opens the way for having a different Piece type for EhInputSection.

llvm-svn: 276275

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

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

llvm-svn: 276121

Creating sections on linkerscript side requires some methods
that can be reused if are exported from writer.

Patch implements that change.

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

llvm-svn: 275162

llvm-svn: 275153

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

Previously, ch_size was read in host byte order, so if a host and
a target are different in byte order, we would produce a corrupted
output.

llvm-svn: 274729

Patch implements support of zlib style compressed sections.
SHF_COMPRESSED flag is used to recognize that decompression is required.
After that decompression is performed and flag is removed from output.

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

llvm-svn: 273661

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

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