[Bug ld/18668] relocation truncated to fit: R_AARCH64_CALL26 (veneers not inserted)

[jiwang at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18668

--- Comment #5 from Jiong Wang <jiwang at gcc dot gnu.org> ---
(In reply to David Abdurachmanov from comment #4)
> I all process libraries except one in OpenLoops, that's enough to trigger
> the issue.
> 
> You can get it here (4.7M):
> http://davidlt.web.cern.ch/davidlt/vault/openloops-1.1.1-stripped.tar.bz2
> 
> $ sha256sum openloops-1.1.1-stripped.tar.bz2
> e8f55e404b1076f8fd8d2f42390e74dad5024d7a3b0a30dd905e4cc981628911 
> openloops-1.1.1-stripped.tar.bz2
> 
> You can trigger compilation via
> 
>     cd openloops-1.1.1-stripped
>     ./openloops update --processes generator=0
> 
> It takes <6 min before linking issue is hit on 8-core APM X-Gene 1. You also
> need at least 4.9 GCC. With 4.8 you would hit an ICE.

I hit an ICE with gcc 4.9.1 on my aarch64 board, then I rebuild above package
using gcc built from svn trunk, the build finished, no linking errors.

I guess this may caused by some new features in gcc trunk reduce code size
slightly that the the branch range can fit into.

Anyway, as documented on AArch64 ELF spec, chapter 4.6.7, we still needs that
st_type == STT_FUNC check, but looks like we are missing the other "or" cases
support:

  * The target symbol has typeSTT_FUNC
  * Or, the target symbol and relocated place are in separate sections input to
the linker.
  * Or, the target symbol is undefined (external to the link unit).

Your main/foo small cases definitely can be fixed by adding a simple input
section check as the symbol defined via "--defsym" is in *ABS* section while
the code itself is in text section.

While for the Openloops failure, I guess it's not enough by only fixing the
first "Or".

But it should not fall into the second "Or" scenario also, as if you are
building shared library, then those undefine symbol should go through PLT stub,
and if you are building exectuable, should not be undefined symbol, otherwise
linking error will happen.

My understanding if you have run into a issue which is:
  * you are building shared library.
  * the function call go through PLT stub.
  * the call to plt stub itself is out of range that triggered
    his relocation truncation error.

Then a further look at AArch64 BFD code shows we don't insert veneer for call
to plt stub while we should.

    if (via_plt_p)
      return stub_type; which is stub_type_none.

will fix this by constructing one hand-written testcase. And I will try gcc
4.9.2 to see if I can reproduce your OpenLoop error to confirm my fix is OK.

-- 
You are receiving this mail because:
You are on the CC list for the bug.