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

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

Hi Adhemerval, sorry for the delay in replying, I was a little under the
weather last week.


On 9/27/23 11:03 AM, Adhemerval Zanella Netto wrote:
> On 26/09/23 19:02, 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.
> 
> This is different than previously exported auxv, where each AT_* constant
> would have a auxv entry. On glibc it would require changing _dl_parse_auxv
> to iterate over the auxv_values to find AT_HWCAP3/AT_HWCAP4 (not ideal, 
> but doable).

When you say different, do you mean because all AUXVs exported by the kernel
*will* have an AT_HWCAP and AT_HWCAP2 entry and AT_HWCAP3/AT_HWCAP4 won't?
I don't think that's a problem for either kernel or glibc side of things.
I'm not even sure there is a guarantee that every AT_* value *must* be
present in the exported AUXV.

The new AT_HWCAP3/AT_HWCAP4 defines are less than AT_MINSIGSTKSZ, so they
don't affect the size of _dl_parse_auxv's auxv_values array size and the
AT_HWCAP3 and AT_HWCAP4 entries in auxv_values[] are already initialized
to zero today.  Additionally, the loop in _dl_parse_auxv already parses
the entire AUXV, so there is no extra work for it to do, unless and until
AT_HWCAP3 and AT_HWCAP4 start being exported by the kernel.  Really, the
only extra work _dl_parse_auxv would need to do, is add two new stores:

  GLRO(dl_hwcap3) = auxv_values[AT_HWCAP3];
  GLRO(dl_hwcap4) = auxv_values[AT_HWCAP4];



> Wouldn't be better to always export it on fs/binfmt_elf.c, along with all 
> the machinery to setup it (ELF_HWCAP3, etc), along with proper documentation?

You mean modify the kernel now to export AT_HWCAP3 and AT_HWCAP4 as zero
masks?  Is that really necessary since we don't need or have any features
defined in them yet?  GLIBC's _dl_parse_auxv doesn't really need them to
be exported either, since in the absence of the entries, it will just end
up using zero masks for dl_hwcap3 and dl_hwcap4, so everything is copacetic
even without any kernel changes.

As I mentioned, our real problem is the lead time for getting changes that
affect the user ABI into a distro release, and ppc's copy/cache of the HWCAP
masks is an ABI change.  If we wait to add this support until when we
actually have a need for HWCAP3, then we won't have any support until
the next major distro release.  However, if we can add this support now,
which I don't think is an onerous change on glibc's part, then we can
start using it immediately when Linux starts exporting them.


Peter