PR28827 - [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu

PR28827 - [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu

[Alan Modra]

Hi Nick, HJ,
I've spent most of today debugging a build of libclang-cpp.so.9 using
the binutils 2.38 release branch.  The problem occurs after only a few
iterations of stub sizing, so all the patches I already committed for
potential bugs when we hit 20 iteration don't so anything as far as
actually linking the real object files.

The problem is caused by the new relro code introducing a gap at the
end of the relro segment.  On powerpc64 that means between the .got
and .plt section.  That gap changes when .eh_frame shrinks after
consolidating CIEs and garbage collecting unused FDEs, which happens
after the stub sizing passes are run from ldemul_after_allocation.
Unfortunately, if the .got/.plt gap increases, plt call stubs may need
to be larger to access addresses in the PLT from the toc pointer reg
and thus not fit in space allocated for them.

Please revert the relro patches on the branch.  I'm now certain that
PR28827 is directly caused by them.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PR28827 - [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu

[H.J. Lu]

On Fri, Feb 4, 2022 at 3:06 AM Alan Modra <amodra@gmail.com> wrote:
>
> Hi Nick, HJ,
> I've spent most of today debugging a build of libclang-cpp.so.9 using
> the binutils 2.38 release branch.  The problem occurs after only a few
> iterations of stub sizing, so all the patches I already committed for
> potential bugs when we hit 20 iteration don't so anything as far as
> actually linking the real object files.
>
> The problem is caused by the new relro code introducing a gap at the
> end of the relro segment.  On powerpc64 that means between the .got
> and .plt section.  That gap changes when .eh_frame shrinks after
> consolidating CIEs and garbage collecting unused FDEs, which happens
> after the stub sizing passes are run from ldemul_after_allocation.
> Unfortunately, if the .got/.plt gap increases, plt call stubs may need
> to be larger to access addresses in the PLT from the toc pointer reg
> and thus not fit in space allocated for them.

I ran into similar issues when I was implementing DT_RELR on x86.
I added size_relative_relocs and finish_relative_relocs hooks to
resolve them.

> Please revert the relro patches on the branch.  I'm now certain that
> PR28827 is directly caused by them.

I submit a patch to remove the 1-page gap only for x86:

https://sourceware.org/pipermail/binutils/2022-February/119625.html

-- 
H.J.