[PATCH v2 1/4] arm64/cpufeature: Store elf_hwcaps as an array rather than unsigned long

[Szabolcs Nagy]

The 06/28/2022 16:06, Mark Brown wrote:
> On Tue, Jun 28, 2022 at 03:21:25PM +0100, Will Deacon wrote:
> > On Mon, Jun 20, 2022 at 01:54:48PM +0100, Mark Brown wrote:
> > > +/* Note that bits 62 and 63 of each AT_HWCAP are reserved */
> 
> > Can you expand a bit on this comment, please? It's not clear who has
> > reserved those bits (e.g. kernel or userspace) and why having two bit
> > reserved means we are limited to 32 instead of 62 bits.
> 
> It's also not clear to me why they're reserved, I didn't manage to dig
> far enough into the history to figure that out - I believe it's a glibc
> thing, or at least something glibc now expects.  Indeed I can't
> immediately dig up the specific reference now.  Szabolcs?  

only the top two bits of AT_HWCAP are reserved for glibc.
(bits of AT_HWCAP2 are not reserved.)

we did the 32bit limit because of ilp32 and i requested to
keep following that.

there is no precedent for using more than 32bit AT_HWCAP nor
precedent for using AT_HWCAP3.

since you are interested in the details...

the reason i slightly preferred AT_HWCAP3 was that AT_HWCAP
is a bit special in ld.so: library lookups can depend on a
glibc internal 64bit "hwcap" value that is historically
AT_HWCAP but since that does not use all bits, some targets
reused the top bits for high level platform abis which we
may want to do on aarch64 too. it should be possible to make
"hwcap" separate from AT_HWCAP (i.e. the bottom 32bits of
"hwcap" just happens to come from AT_HWCAP but the top is
defined by glibc), but that would be awkward to do in the
ld.so code if AT_HWCAP started using the top bits too.
(i think we cannot change the "hwcap" bits once they are
allocated because they are in the ld.so.cache file.)

so the options are:

- AT_HWCAP3. (the only option that's ilp32 compatible.)

- start using top bits of AT_HWCAP2 but not of AT_HWCAP.
  (this is the least amount of work for now)

- i go and fix ld.so code so top bits of internal "hwcap"
  are independent of AT_HWCAP. (we might need to bump the
  ld.so.cache file format version for this, which happened
  22 years ago last time.. this needs more investigation)

- start using AT_HWCAP top bits and we don't care about
  the future of "hwcap" ld.so feature. this is rarely used,
  but i think it may become useful. e.g. it would allow us
  to define a new base line arch abi for distros (so they
  can ship some libs built twice: once for base armv8.0 and
  once for the new base line and ld.so would pick the right
  lib based on hwcaps/feature checks). i would avoid this.