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

[Mark Brown]

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?

> so the options are:

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

It's also a precedent we can follow when we run out of bits again which
does seem like a thing that will plausibly happen.

> - 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)

This does sound like disproportionate effort TBH.

> - 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220629/cba98b88/attachment.sig>