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. Peter
