This reduces the size of SharedSymbol which in turn reduces the size
of Symbol from 88 to 80 bytes.

llvm-svn: 313154

The patch implements initial support of microMIPS code linking:
  - Handle microMIPS specific relocations.
  - Emit both R1-R5 and R6 microMIPS PLT records.

For now linking mixed set of regular and microMIPS object files is not
supported. Also the patch does not handle (setup and clear) the
least-significant bit of an address which is utilized as the ISA mode
bit and allows to make jump between regular and microMIPS code without
any thunks.

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

llvm-svn: 313028

Replace OutputSection *Cmd to OutputSection *OS. The Commands vector was
moved to OutputSection but the names of the variables were not. This patch
changes the names to match.

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

llvm-svn: 313015

This is PR32429.

We did not mention -fPIC in error about producing dynamic relocation
in readonly segment before. Patch changes that.

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

llvm-svn: 312003

Currently LLD reads the R_MIPS_HI16's addends in the `computeMipsAddend`
function, the R_MIPS_LO16's addends in both `computeMipsAddend` and
`getImplicitAddend` functions. This patch moves reading all addends to
the `getImplicitAddend` function. As a side effect it fixes a "paired"
HI16/LO16 addend calculation if "LO16" part of a pair is not found.

llvm-svn: 311711

This is probably a small optimization, but the main motivation is
having a way of fixing pr34053 that doesn't require a hash lookup in
isPreempitible.

llvm-svn: 310602

With this Symbol has the same size as before, but DefinedRegular goes
from 72 to 64 bytes.

I also find this a bit easier to read. There are fewer places
initializing File for example.

This has a small but measurable speed improvement on all tests (1%
max).

llvm-svn: 310142

When reporting an invalid relocation we were blaming the destination
file instead of the file with the relocation.

llvm-svn: 310084

llvm-svn: 310079

Reviewing another change I noticed that we use "getSymbols" to mean
different things in different files. Depending on the file it can
return

ArrayRef<StringRef>
ArrayRef<SymbolBody*>
ArrayRef<Symbol*>
ArrayRef<Elf_Sym>

With this change it always returns an ArrayRef<SymbolBody*>. The other
functions are renamed getELFsyms() and getSymbolNames().

Note that we cannot return ArrayRef<Symbol*> instead of
ArreyRef<SymbolBody*> because local symbols have a SymbolBody but not
a Symbol.

llvm-svn: 309840

This is a bit of a hack, but it is *so* convenient.

Now that we create synthetic linker scripts when none is provided, we
always have to handle paired OutputSection and OutputsectionCommand and
keep a mapping from one to the other.

This patch simplifies things by merging them and creating what used to
be OutputSectionCommands really early.

llvm-svn: 309311

NFC, just makes it easier to access from non templated code.

llvm-svn: 309152

Previously we handled this option implicitly, only
for infering unresolved symbols handling policy.

ld man says: "--noinhibit-exec Retain the executable
output file whenever it is still usable",
and we may want to handle other cases too.

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

llvm-svn: 309091

llvm-svn: 308297

This code runs after clearOutputSections.

llvm-svn: 308066

llvm-svn: 308057

NFC, just makes the OutputSectionCommand available.

llvm-svn: 308056

llvm-svn: 307211

Attempt to fix Windows buildbots From 307131 Replaced return {ET, false};
with return std::make_pair(ET, false);

llvm-svn: 307137

This change permits there to be more than one thunk to be associated with
a symbol. For interworking thunks we only require one thunk, but range
extension thunks may require more than one.

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

llvm-svn: 307136

On ARM the interworking thunks are only produced for branch instructions
that can't be changed into a blx instruction so only Thumb callers would
call Thumb thunks and only ARM callers would call ARM thunks. With range
extension thunks branch and link instructions may need a Thunk. These
instructions can be rewritten as a blx and can use either ARM or Thumb
thunks.

We introduce an isCompatibleWith() function so that a caller can check if
an existing Thunk is compatible before reusing it.

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

llvm-svn: 307132

Before we would sometimes not mention that the relocation was in a ro
area before.

llvm-svn: 307089

On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - .
and produce a relocation that can be processed without needing to know the
value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM
gcc produces R_ARM_BASE_PREL but clang produces the more general
R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation
correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of
the GOT or end of the GOT dependent on architecture..

If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this
change will not be necessary for new objects. However there may still be
old objects and versions of clang.

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

llvm-svn: 306282

    
In preparation for supporting range extension thunks we now continually
call createThunks() until no more thunks are added. This requires us to
record the thunks we add on each pass and only merge the new ones into the
OutputSection. We also need to check if a Relocation is targeting a thunk
to prevent us from infinitely creating more thunks.
    
Differential Revision: https://reviews.llvm.org/D34034

llvm-svn: 305555

This allows moving clearOutputSections a bit earlier.

llvm-svn: 304947

Thunks are now generated per InputSectionDescription instead of per
OutputSection. This allows created ThunkSections to be inserted directly
into InputSectionDescription.

Changes in this patch:
- Loop over InputSectionDescriptions to find relocations to Thunks
- Generate a ThunkSection per InputSectionDescription
- Remove synchronize() as we no longer need it
- Move fabricateDefaultCommands() before createThunks

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

llvm-svn: 304887

In preparation for inserting Thunks into InputSectionDescription::Sections
extract the loop that finds InputSections that may have calls that need
Thunks. This isn't much benefit now but this will be useful when we have to
extract the InputSectionDescriptions::Sections from the script.

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

llvm-svn: 304783

In preparation for inserting Thunks into InputSectionDescriptions this
simple change associates added Thunks with a vector of InputSections instead
of an OutputSection. As of now we are just using OutputSection::Sections.

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

llvm-svn: 304782

This is PR33243. R_GOTONLY_PC_FROM_END was not in a list of link time constant
expressions and that was a result of confusiing messages like PR shows:

/usr/bin/ld.lld: error: /usr/lib/go/src/runtime/alg.go:47: 
can't create dynamic relocation R_386_GOTPC against local symbol in readonly segment defined in /tmp/nice/go-link-597453838/go.o

Though in reality we just should not have try to create a dynamic relocation for this case at all.

Patch fixes the issue.

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

llvm-svn: 304393

Before InputSectionBase had an OutputSection pointer, but that was not
always valid. For example, if it was a merge section one actually had
to look at MergeSec->OutSec.

This was brittle and caused bugs like the one fixed by r304260.

We now have a single Parent pointer that points to an OutputSection
for InputSection, but to a SyntheticSection for merge sections and
.eh_frame. This makes it impossible to accidentally access an invalid
OutSec.

llvm-svn: 304338

GetSection is a template because write calls relocate.

relocate has two parts. The non alloc code really has to be a
template, as it is looking a raw input file data.

The alloc part is only a template because of getSize.

This patch folds the value of getSize early, detemplates
getRelocTargetVA and splits relocate into a templated non alloc case
and a regular function for the alloc case. This has the nice advantage
of making sure we collect all the information we need for relocations
before getting to InputSection::relocateNonAlloc.

Since we know got is alloc, it can just call the function directly and
avoid the template.

llvm-svn: 303355

Nothing special here, just detemplates code that became possible 
to detemplate after recent commits in a straghtforward way.

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

llvm-svn: 303237

This is a bit hackish, but allows for a lot of followup cleanups.

llvm-svn: 302845

llvm-svn: 302832

llvm-svn: 302828

llvm-svn: 302826

This feels a bit hackish, but I think it is still an improvement.

The way a tls address is computed in the various architectures is not
that different. For example, for local dynamic we need the base of the
tls (R_TLSLD or R_TLSLD_PC), and the offset of that particular symbol
(R_ABS).

Given the similarity, we can just use the expressions instead of
having two additional target hooks.

llvm-svn: 302279

It seems virtually everyone who tries to do LTO build with Clang and
LLD was hit by a mistake to forget using llvm-ar command to create
archive files. I wasn't an exception. Since this is an annoying common
issue, it is probably better to handle that gracefully rather than
reporting an error and tell the user to redo build with different
configuration.

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

llvm-svn: 302083

    
Replace addModuleReloc with AddTlsReloc so that we can use it for both the
module relocation and the offset relocation.

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

llvm-svn: 300192

Previously we silently produced broken output for R_386_GOT32X/R_386_GOT32 
relocations if they were used to compute the address of the symbol’s global
offset table entry without base register when position-independent code is disabled.

Situation happened because of recent ABI changes. Released ABI mentions that
R_386_GOT32X can be calculated in a two different ways (so we did not follow ABI here 
before this patch), but draft ABI also mentions R_386_GOT32 relocation here. 
We should use the same calculations for both relocations.

Problem is that we always calculated them as G + A - GOT (offset from end of GOT),
but for case when PIC is disabled, according to i386 ABI calculation should be G + A,
what should produce just an address in GOT finally.

ABI: https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-draft.pdf (p36, p60).
llvm-svn: 299812