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:

quoted

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