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

Szabolcs Nagy szabolcs.nagy at arm.com
Wed Jun 29 05:06:10 PDT 2022


The 06/29/2022 12:44, Mark Brown wrote:
> On Wed, Jun 29, 2022 at 11:01:43AM +0100, Szabolcs Nagy wrote:
> 
> > 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 when you were saying that bits 62 and 63 were reserved it's actually
> potentially all the top 32 bits but only in plain AT_HWCAP?
> 

currently only bits 62 and 63 are reserved and only in plain AT_HWCAP.

and yes it might be useful to reserve all top 32bits of AT_HWCAP.
(for glibc internal reasons those are easy to use for ld.so extensions).



More information about the linux-arm-kernel mailing list