[PATCH v3] aarch64: add support for hwcap3,4

[enh]

On Wed, Apr 23, 2025 at 11:41 AM Yury Khrustalev
<yury.khrustalev@arm.com> wrote:
>
>
> On Wed, Apr 23, 2025 at 11:35:17AM -0400, enh wrote:
> > > > However, now we also have a bit of naming inconsistency, as pointed by
> > > > Chris (on CC):
> > > >
> > > >   AT_HWCAP --> arg->_hwcap_array[0]
> > > >   AT_HWCAP2 --> arg->_hwcap_array[1]
> > > >   AT_HWCAP3 --> arg->_hwcap_array[2]
> > > >   AT_HWCAP4 --> arg->_hwcap_array[3]
> > > >
> > > > So, n-th element in the array is **not** AT_HWCAP{n}. This seems error-prone.
> > > > We could introduce an enum for more readable indices or a helper function
> > > > discussed earlier in this thread, but it wouldn't be part of the original
> > > > interface and nobody might use it, so it won't be too useful anyway.
> > >
> > > did you read fweimer's suggestion? what was so clever about it was
> > > that it solves this problem...
>
> It may solve this problem but all existing code will not compile with new Glibc
> headers, right? unless I'm missing something here.

two #defines solve that.

> And the new access function
> will not be available without new header.

that's true _regardless_ of solution --- "if you need the new stuff
... you need a new header".

(though another clever thing about fweimer's solution is that it means
that's not true next time, when AT_HWCAP5 goes in.)

> And what about code that uses the
> __ifunc_arg_t struct name which we'd delete in favour of the new resolver interface?

why delete it? you can always keep that for backwards source
compatibility. (as Android would.)