Re: [PATCH] powerpc: Define USE_PPC64_NOTOC iff compiler and linker also supports it

[Alan Modra <amodra@gmail.com>]

On Tue, Nov 16, 2021 at 04:42:15PM -0300, Tulio Magno Quites Machado Filho wrote:
> Alan Modra via Libc-alpha <libc-alpha@sourceware.org> writes:
> 
> > I have a question about powerpc64/ppc-mcount.S.  Why is the assembly
> > wrapper using ENTRY and a NOTOC call?  By using ENTRY you are saying
> > that calls to _mcount must have r2 valid.  Given that r2 is valid, why
> > then use NOTOC?
> 
> I wouldn't be surprised if that was a misinterpretation of the ABI on my part.
> 
> Looking at table 2.20 "Protocols for Local Function Calls", I think this is a
> scenario that falls to the last row of this table, where we have:

As Bill said, the ABI does define what is meant by local.  However, it
is true that if you have enough control over the full build process
(you never do when !SHARED in glibc) and know what you're doing, you
may use a wider definition of "local".  It's something like "I know
this function linkage will be exactly the same as a static function in
the current compilation unit".  Which implies known local definition
at link time that cannot be overridden, *and* same toc group.  The
latter condition is often forgotten, and bites people using ELFv1
-mcmodel=small code when the TOC exceeds 64k.

> - Local call method
> - nop is not needed
> - Relocation is R_PPC64_REL24_NOTOC.
> 
> If this interpretation is incorrect, what is the recommended solution for this
> case? Use ENTRY_TOCLESS?

If you use ENTRY_TOCLESS you are saying that the function neither uses
nor changes r2.  This situation is not covered by table 2.19 or 2.20
in the ABI, because ENTRY_TOCLESS functions generally do not make
calls!  There is a note saying that it is not forbidden but then *you*
must ensure that the call does not change r2.  Now it might be that
__mcount_internal currently does not change r2, but that won't
necessarily hold for all future compilers.  Power10 pcrel code may use
r2 as a scratch register..

I recommend losing the NOTOC on the call.  You already have the nop
after the call when !SHARED, which is correct and necessary for a
normal call.  You also likely have enough control over SHARED builds
to omit the nop in that case.

Note that having a localentry:8 _mcount is not ideal if someone wants
to build -mcpu=power10 glibc, but _mcount is quite a way down on the
priority list of removing localentry:8 functions for -mcpu=power10.

-- 
Alan Modra
Australia Development Lab, IBM