ppc64 ld : linker synthesized _savegpr* and _restgpr*

[Alan Modra]

On Tue, May 05, 2020 at 05:37:57PM -0700, Fangrui Song wrote:
> On 2020-05-06, Alan Modra wrote:
> > On Tue, May 05, 2020 at 03:41:04PM -0700, Fangrui Song wrote:
> > > Isn't it cleaner and more elegant to define these functions in libgcc, like
> > > everything else does?
> > 
> > No, and there is another benefit to having the linker generate
> > out-of-line register save and restore functions: If the binary is so
> > large that "bl" can't reach them from some location, the linker
> > inserts multiple copies of those functions rather than bouncing
> > through long branch trampolines.
> 
> But why are _savegpr* and _restgpr* given first-class priorities?
> (linker defined as opposed to runtime libs)
> 
> 
> cat > a.s <<e
>   .globl _start; _start:
>     bl _savegpr0_20
>     nop
>     .space (1<<25)
>     bl _savegpr0_20
>     nop
> e
> 
> powerpc64le-linux-gnu-gcc -nostdlib a.s -o a
> => (verified with binutils HEAD built with ./configure --target=powerpc64le)
> 
> (.text+0x2000008): relocation truncated to fit: R_PPC64_REL24 (stub) against symbol `_savegpr0_20' defined in .sfpr section in linker stubs

Yes, that doesn't work.  You've made a single very large section with
no place to insert stubs between the two calls, and the linker isn't
clever enough to insert stubs for a particular section both before and
after that section.

> 
> STB_LOCAL also looks a bit strange.
> 
> What shall happen if the functions are taken address?

They aren't normal functions.  Taking their address is undefined.

-- 
Alan Modra
Australia Development Lab, IBM