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

[ELF] Do not pass GOT section as an argument to handleARMTlsRelocation and handleMipsTlsRelocation functions. NFC

Both functions always use the same GOT sections In<ELFT>::Got and
In<ELFT>::MipsGot respectively, so we do not need to pass them as an
argument.

llvm-svn: 299773

    
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

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

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

llvm-svn: 299722

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

    
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

Previous error message style:

  error: /home/alice/src/bar.c:12: relocation R_X86_64_PLT32 cannot refer to absolute symbol 'answer' defined in /home/alice/src/foo.o

New error message style:

  error: relocation R_X86_64_PLT32 cannot refer to absolute symbol: foo
  >>> defined in /home/alice/src/foo.o
  >>> referenced by bar.c:12 (/home/alice/src/bar.c:12)
  >>>               /home/alice/src/bar.o:(.text+0x1)

llvm-svn: 299390

llvm-svn: 299208

This change is to improve consistency with other files.

llvm-svn: 299110

Previously, undefined symbol errors are one line like this
and wasn't easy to read.

  /ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:207: undefined symbol 'lld::elf::EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true> >::addSection(lld::elf::InputSectionBase*)'

This patch make it more structured like this.

  bin/ld.lld: error: undefined symbol: lld::elf::EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true>
  >>> Referenced by Writer.cpp:207 (/ssd/llvm-project/lld/ELF/Writer.cpp:207)
  >>>               Writer.cpp.o in archive lib/liblldELF.a

Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html

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

llvm-svn: 299097

This reverts commit because this really shouldn't happen unless
there's a bug in LLD.

llvm-svn: 299021

uint64_t is simpler and less error-prone than target or host-dependent types.

llvm-svn: 298969

If a function takes a size and an alignment, we usually pass them
in that order instead of the reverse order.

llvm-svn: 298968

This patch calls getAddend on a relocation only when the relocation is RELA.
That doesn't really improve runtime performance but should improve
readability as the code now matches the function description.

llvm-svn: 298828

llvm-svn: 298821

llvm-svn: 298818

Previously, computeAddend had many parameters but most of them were
used only for MIPS. The MIPS ABI is too odd that I don't want to mix
it into the regular code path. Splitting the function into non-MIPS
and MIPS parts makes the regular code path easy to follow.

llvm-svn: 298817

llvm-svn: 298815

llvm-svn: 298814

llvm-svn: 298796

llvm-svn: 298795

llvm-svn: 298794

llvm-svn: 298793

llvm-svn: 298792

llvm-svn: 298790

llvm-svn: 298789

llvm-svn: 298788

llvm-svn: 298787

C is short for Chunk, but we are no longer using that term.
RI is probably short for relocation iterator, but this is not an interator.

llvm-svn: 298786

Previously, relocation offsets are recalculated for .eh_frame sections
inside the main loop, and that messed up the main loop. This patch
separates that logic into a dedicated class.

llvm-svn: 298785

llvm-svn: 298748

llvm-svn: 298675

The original code is a big `if` and `else` which ends with `continue`
like this:

  if (cond) {
    ...
    // fall through
  } else {
    ...
    continue;
  }

This patch rewrites it with the following.

  if (!cond) {
    ...
    continue;
  }
  ...

llvm-svn: 298672

I honestly do not understand this part of code as it is too tangled.
What I'm trying now is to carefully disentangle it by transforming
code without changing meaining to see if I can improve overall
readability.

llvm-svn: 298576

llvm-svn: 298575

The patch introduces two new relocations expressions R_MIPS_GOT_GP and
R_MIPS_GOT_GP_PC. The first one represents a current value of `_gp`
pointer and used to calculate relocations against the `__gnu_local_gp`
symbol. The second one represents the offset between the beginning of
the function and the `_gp` pointer's value.

There are two motivations for introducing new expressions:
- It's better to keep all non-trivial relocation calculations in the
  single place - `getRelocTargetVA` function.
- Relocations against both `_gp_disp` and `__gnu_local_gp` symbols
  depend on the `_gp` value. It's a magical value points to the "middle"
  of GOT. Now all relocations use a common `_gp` value. But in fact,
  under some conditions each input file might require its own `_gp`
  value. I'm going to implement it in the future patches. So it's
  better to make `MipsGotSection` responsible for calculation of
  the `_gp` value.

llvm-svn: 298306

We had a few Config member functions that returns configuration values.
For example, we had is64() which returns true if the target is 64-bit.
The return values of these functions are constant and never change.

This patch is to compute them only once to make it clear that they'll
never change.

llvm-svn: 298168

recommend using llvm-ar when finding undefined references and empty archives

Summary:
When we perform LTO builds with a version of ar that does not
understand LLVM bitcode objects, we end up with undefined references,
because our archive files do not list the bitcode symbols in their
indices. The error messages do not make it clear what the real problem
is. This change adds a note that points out the likely problem and
solution. It is similar in spirit to r282633, but aims to avoid false
positives by only triggering when we see both undefined references and
archives without symbols in their indices.

Fixes PR32281.

Reviewers: davide, ruiu, tejohnson

Subscribers: llvm-commits

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

llvm-svn: 298124