Re: [PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries

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

On 10/3/23 9:08 AM, Adhemerval Zanella Netto wrote:
> What it is not clear to me is what kind of ABI boundary you are trying to
> preemptively add support here. The TCB ABI for __builtin_cpu_supports is
> userland only, so if your intention is just to allow gcc to work on older
> glibcs, it should be a matter to just reserve the space on tcbhead_t.

Yes, extending tcbhead_t to contain the slots for hwcap3 and hwcap4 are the
ABI extensions we are interested in, and not something that can be backported
into a distro point release.  Yes, we don't strictly need the AT_HWCAP3 and
AT_HWCAP4 kernel defines to reserve (and clear) that space in glibc, but....



> If your intention is to also add support on glibc, it makes more sense to
> already reserve it.  For __builtin_cpu_supports it should work, although
> for glibc itself some backporting would be required (to correctly showing
> the bits with LD_SHOW_AUXV).

Our intention is to also add the glibc support too once we have the
AT_HWCAP3 and AT_HWCAP4 kernel macros defined.  1) Once the defines are
there, adding the support should be pretty straight forward, so why wait?
And 2) part of the glibc and compiler support introduces a new symbol
that is exported by glibc and referenced by the compilers to ensure the
compilers *never* access the hwcap* fields in the TCB unless the glibc
supports them.  See the symbol __parse_hwcap_and_convert_at_platform used
for HWCAP/HWCAP2.  We'll need a similar one for HWCAP3/HWCAP4 and I'm
doubtful whether the distros will allow the backport of a patch that
introduces a new exported symbol from glibc in a distro point release.


Peter