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.
