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

llvm-svn: 298091

llvm-svn: 298072

Error was:
Relocations.cpp:792:38: error: expected primary-expression before ‘>’ token
         In<ELFT>::Iplt->addEntry<ELFT>(Body);

llvm-svn: 298070

Alternative approach can be remove templated method
either, like D31028 do.

llvm-svn: 298065

Was fixed, details on review page.

Original commit message:

That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.

This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.

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

llvm-svn: 298062

That opens road to detemplate PltSection<ELFT>,
what allows then to detemplate all methods of SymbolBody.

llvm-svn: 297950

llvm-svn: 297942

llvm-svn: 297941

llvm-svn: 297939

llvm-svn: 297937

I suppose it is the reason of BB fail:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/921

https://bugs.llvm.org/show_bug.cgi?id=32167

llvm-svn: 297933

That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.

This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.

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

llvm-svn: 297814

Being passed -z notext is a pretty strong indication that the user is
OK with text relocations. This is not the same behavior as bfd, but
bfd defaults to -z notext, so it has to try to avoid text relocations
and use them as a last resort.

llvm-svn: 297789

gold linker manual describes them as:

-z text	Do not permit relocations in read-only segments
-z notext Permit relocations in read-only segments (default)

In LLD default is to not permit them. Patch implements -z notext.

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

llvm-svn: 297366

This reverts commit r297008 because it's reported that that
change broke AArch64 bots.

llvm-svn: 297297

llvm-svn: 297287

    
This change moves the calls to finalizeContent() for each synthetic section
before createThunks(). This will allow us to assign addresses prior to
calling createThunks(). As addition of thunks may add to the static
symbol table and may affect the size of the mips got section we introduce a
couple of additional member functions to update these values.
    
Differential revision: https://reviews.llvm.org/D29983

llvm-svn: 297277

    
This change fixes a bug in which the Mips LA25 Thunks are always assigned
to the same Output section as the caller and not the callee as expected.

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

llvm-svn: 297135

llvm-svn: 297107

llvm-svn: 297077

llvm-svn: 297012

In compare with D30458, this makes Bss/BssRelRo to be pure
synthetic sections.

That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.

SharedSymbols involved in creating copy relocations are
converted to DefinedRegular, what also simplifies things.

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

llvm-svn: 297008

In many places we reset Size to 0 before calling assignOffsets()
manually. Sometimes we don't do that. 
It looks we can just always do that inside.

Previous code had:
template <class ELFT> void OutputSection::assignOffsets() {
  uint64_t Off = Size;

And tests feels fine with Off = 0. 
I think Off = Size make no sence.

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

llvm-svn: 296609

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

llvm-svn: 296508

llvm-svn: 296307

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

llvm-svn: 296303