[PowerPC64] Use medium model toc accesses throughout

  The PowerPC64 linker edits medium model toc-indirect code to toc-pointer
relative:
	addis r9,r2,tc_entry_for_var@toc@ha
	ld r9,tc_entry_for_var@toc@l(r9)
becomes
	addis r9,r2,(var-.TOC.)@ha
	addi r9,r9,(var-.TOC.)@l
when "var" is known to be local to the binary.  This isn't done for
small-model toc-indirect code, because "var" is almost guaranteed to
be too far away from .TOC. for a 16-bit signed offset.  And, because
the analysis of which .toc entry can be removed becomes much more
complicated in objects that mix code models, they aren't removed if
any small-model toc sequence appears in an object file.

Unfortunately glibc's build of ld.so smashes the needed objects
together in a ld -r linking stage.  This means the GOT/TOC is left
with a whole lot of relative relocations which is untidy, but in
itself is not a serious problem.  However, static-pie on powerpc64
bombs due to a segfault caused by one of the small-model accesses
before _dl_relocate_static_pie.  (The very first one in rcrt1.o
passing start_addresses in r8 to __libc_start_main.)

So this patch makes all the toc/got accesses in assembly medium code
model, and a couple of functions hidden.  By itself this is *not*
enough to give us working static-pie, but it is useful anyway to
enable better linker optimisation.

There's a serious problem in libgcc too.  libgcc ifuncs access the
AT_HWCAP words stored in the tcb with an offset from the thread
pointer (r13), but r13 isn't set at the time _dl_relocate_static_pie
runs, and I'm loathe to try calling init_tls early.  A better approach
that might work is to fake r13 so that _dl_hwcap is at the expected
offset where we'd normally find the tcb hwcap words.

Tested for regressions with a powerpc64le-linux build and test run.
OK to apply?
  

On 1/23/22 6:42 AM, Alan Modra via Libc-alpha wrote:
> The PowerPC64 linker edits medium model toc-indirect code to toc-pointer
> relative:
> 	addis r9,r2,tc_entry_for_var@toc@ha
> 	ld r9,tc_entry_for_var@toc@l(r9)
> becomes
> 	addis r9,r2,(var-.TOC.)@ha
> 	addi r9,r9,(var-.TOC.)@l
> when "var" is known to be local to the binary.  This isn't done for
> small-model toc-indirect code, because "var" is almost guaranteed to
> be too far away from .TOC. for a 16-bit signed offset.  And, because
> the analysis of which .toc entry can be removed becomes much more
> complicated in objects that mix code models, they aren't removed if
> any small-model toc sequence appears in an object file.
> 
> Unfortunately glibc's build of ld.so smashes the needed objects
> together in a ld -r linking stage.  This means the GOT/TOC is left
> with a whole lot of relative relocations which is untidy, but in
> itself is not a serious problem.  However, static-pie on powerpc64
> bombs due to a segfault caused by one of the small-model accesses
> before _dl_relocate_static_pie.  (The very first one in rcrt1.o
> passing start_addresses in r8 to __libc_start_main.)
> 
> So this patch makes all the toc/got accesses in assembly medium code
> model, and a couple of functions hidden.  By itself this is *not*
> enough to give us working static-pie, but it is useful anyway to
> enable better linker optimisation.
> 
> There's a serious problem in libgcc too.  libgcc ifuncs access the
> AT_HWCAP words stored in the tcb with an offset from the thread
> pointer (r13), but r13 isn't set at the time _dl_relocate_static_pie
> runs, and I'm loathe to try calling init_tls early.  A better approach
> that might work is to fake r13 so that _dl_hwcap is at the expected
> offset where we'd normally find the tcb hwcap words.
> 
> Tested for regressions with a powerpc64le-linux build and test run.
> OK to apply?
> 

> diff --git a/sysdeps/powerpc/powerpc64/dl-trampoline.S b/sysdeps/powerpc/powerpc64/dl-trampoline.S
> index 23debc2faf..45b821607b 100644
> --- a/sysdeps/powerpc/powerpc64/dl-trampoline.S
> +++ b/sysdeps/powerpc/powerpc64/dl-trampoline.S
> @@ -32,6 +32,7 @@
>      because gcc as of 2010/05 doesn't allocate a proper stack frame for
>      a function that makes no calls except for __tls_get_addr and we
>      might be here resolving the __tls_get_addr call.  */
> +	.hidden _dl_runtime_resolve
>   #define INT_PARMS FRAME_MIN_SIZE
>   ENTRY (_dl_runtime_resolve, 4)
>   	stdu	r1,-FRAME_SIZE(r1)
> @@ -195,6 +196,7 @@ END(_dl_runtime_resolve)
>      parm1 (r3) and the index (r0) needs to be converted to an offset
>      (index * 24) in parm2 (r4).  */
>   #ifndef PROF
> +	.hidden _dl_profile_resolve
>   ENTRY (_dl_profile_resolve, 4)
>   /* Spill r30, r31 to preserve the link_map* and reloc_addr, in case we
>      need to call _dl_audit_pltexit.  */

LGTM (this should wait until after the freeze), though these two changes 
seem orthogonal to the commit title.

For my education, why are are small model accesses used in these files?
  

On Fri, Jan 28, 2022 at 11:48:44AM -0600, Paul E Murphy wrote:
> > --- a/sysdeps/powerpc/powerpc64/dl-trampoline.S
> > +++ b/sysdeps/powerpc/powerpc64/dl-trampoline.S
> > @@ -32,6 +32,7 @@
> >      because gcc as of 2010/05 doesn't allocate a proper stack frame for
> >      a function that makes no calls except for __tls_get_addr and we
> >      might be here resolving the __tls_get_addr call.  */
> > +	.hidden _dl_runtime_resolve
> >   #define INT_PARMS FRAME_MIN_SIZE
> >   ENTRY (_dl_runtime_resolve, 4)
> >   	stdu	r1,-FRAME_SIZE(r1)
> > @@ -195,6 +196,7 @@ END(_dl_runtime_resolve)
> >      parm1 (r3) and the index (r0) needs to be converted to an offset
> >      (index * 24) in parm2 (r4).  */
> >   #ifndef PROF
> > +	.hidden _dl_profile_resolve
> >   ENTRY (_dl_profile_resolve, 4)
> >   /* Spill r30, r31 to preserve the link_map* and reloc_addr, in case we
> >      need to call _dl_audit_pltexit.  */
> 
> LGTM (this should wait until after the freeze), though these two changes
> seem orthogonal to the commit title.

True.  It could have been a separate patch.

> For my education, why are are small model accesses used in these files?

dl-trampoline.S is an old file, from before the linker edited
toc-indirect code to toc-pointer relative.  Without the link editing
small model is more efficient if the toc is small enough.