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
