CCing linux-kernel for more exposure.
PING. I'm waiting on a reply from anyone on the kernel side of things
to see whether they have an issue with reserving values for AT_HWCAP3
and AT_HWCAP4.
I'll note reviews from the GLIBC camp did not have an issue with the below patch.
Thanks.
Peter
On 9/26/23 5:02 PM, Peter Bergner wrote:
> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
> access by our __builtin_cpu_supports built-in function. The TCB space for
> the HWCAP entries - which are created in pairs - is an ABI extension, so
> waiting to create the space for HWCAP3 and HWCAP4 until we need them is
> problematical, given distro unwillingness to apply ABI modifying patches
> to distro point releases. Define AT_HWCAP3 and AT_HWCAP4 in the generic
> uapi header so they can be used in GLIBC to reserve space in the powerpc
> TCB for their future use.
>
> I scanned both the Linux and GLIBC source codes looking for unused AT_*
> values and 29 and 30 did not seem to be used, so they are what I went
> with. If anyone sees a problem with using those specific values, I'm
> amenable to using other values, just let me know what would be better.
>
> Peter
>
>
> Signed-off-by: Peter Bergner <[email protected]>
> ---
> include/uapi/linux/auxvec.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
> index 6991c4b8ab18..cc61cb9b3e9a 100644
> --- a/include/uapi/linux/auxvec.h
> +++ b/include/uapi/linux/auxvec.h
> @@ -32,6 +32,8 @@
> #define AT_HWCAP2 26 /* extension of AT_HWCAP */
> #define AT_RSEQ_FEATURE_SIZE 27 /* rseq supported feature size */
> #define AT_RSEQ_ALIGN 28 /* rseq allocation alignment */
> +#define AT_HWCAP3 29 /* extension of AT_HWCAP */
> +#define AT_HWCAP4 30 /* extension of AT_HWCAP */
>
> #define AT_EXECFN 31 /* filename of program */
>
The 10/17/2023 18:14, Peter Bergner wrote:
> CCing linux-kernel for more exposure.
>
> PING. I'm waiting on a reply from anyone on the kernel side of things
> to see whether they have an issue with reserving values for AT_HWCAP3
> and AT_HWCAP4.
>
> I'll note reviews from the GLIBC camp did not have an issue with the below patch.
fwiw, aarch64 is quickly filling up AT_HWCAP2 so this will be
useful for arm64 too eventually, but we are not in a hurry.
> > +#define AT_HWCAP3 29 /* extension of AT_HWCAP */
> > +#define AT_HWCAP4 30 /* extension of AT_HWCAP */