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

[Adhemerval Zanella Netto]

On 03/10/23 19:12, Peter Bergner wrote:
> 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.

Alright, I makes more sense it now.  And indeed backporting a __parse_hwcap
for HWCAP3/HWCAP4 will be frown upon.