Re: [PATCH v3] PowerPC: Influence cpu/arch hwcap features via GLIBC_TUNABLES.

[Peter Bergner <bergner@linux.ibm.com>]

On 7/7/23 9:25 AM, Adhemerval Zanella Netto wrote:
> The set_hwcaps is called once only at process execution. Adding bits might
> make sense in a scenario that you are running a new glibc on older kernels
> and you know that some string routines are safe to run on that hardware
> (although it might come with some caveats, since it might still require some
> kernel support).

AIUI, on Power, the firmware (which knows about the "new" hardware features
on the cpu we're running on) passes the HWCAP/HWCAP2 masks to the kernel.
The kernel (old or new) then places those masks (even the new ones it doesn't
know about/understand) into the AUXV that is passed to glibc, so we don't
have a problem with "old" kernels and the HWCAP/HWCAP2 masks glibc receives
from the kernel should be "full-featured" wrt the cpu it is running on.

This is why I was mentioning I'm not sure supporting adding bits to the masks
makes any sense on Power, unless there is a mechanism where we might have
removed some earlier.  It sounds like from your comment that there isn't a way
for that to happen.  That said, keeping the tunable API the same across the
different architectures the same is important, so we should at least accept
the user trying...it just won't do anything. :-)



> With this patch GLIBC_TUNABLES=glibc.cpu.hwcaps=feature is ignored if 'feature'
> is not support by HWCAP/2, which is not explicit state in documentation and
> it slight differ from s390x/x86. The s390x only considers features that are 
> used in ifunc resolver, but since the idea is to use __builtin_cpu_supports
> maybe powerpc should handle everything.

Since our (old or new) kernel supplied HWCAP/HWCAP2 masks are full-featured,
it makes sense on Power not to allow users to set any bits that were not set
in the original hwcap masks, since we "know" the underlying hardware doesn't
support them.

I believe Mahesh's current patch only supports modifying the internal to
glibc ifunc resolvers, but I do want them to eventually be made externally
available for use by the __builtin_cpu_supports() built-in.



> It also bothers me that our documentation references to a source file to
> actually get the supported 'features' strings.  I think we can make it better
> and proper document the correct list of features and maybe add a ld.so
> option to also print the supported values.

I like that idea.  That said, GCC documents the 'features' as part of the
__builtin_cpu_supports built-in documentation:

  https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html

...but the user should be able to get this from glibc documentation
since the tunables is a glibc feature (wow, too many features :-).

Peter