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

[Yury Khrustalev]

Hi,

I'll post v4 shortly that should hopefully address the concerns raised in this
discussion.

On Thu, Apr 24, 2025 at 11:17:45AM -0400, enh wrote:
> On Thu, Apr 24, 2025 at 4:54 AM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
> ... 
> i think the suggestion was:
> 
> 1. __ifunc_arg_t stays as it is.

I think that would be wrong to keep "partially defined" struct in the API
headers. We should extend it as we add new HWCAP fields. If you think that
this header will asymptotically become useful, like you mention below, it's
one more reason to update this struct.

> 2. the libcs start treating the ifunc resolvers as if their argument
> was actually an `unsigned long[]`, where the first elements match the
> historical __ifunc_arg_t and newer hwcaps follow on the end.

Glibc will always have it's own header sys/ifunc.h so why not use it for
internal purposes, e.g. in the elf_ifunc_invoke() function? However, as
far as resolvers are concerned, they should treat second parameter as
`unsigned long[]` provided that this buffer has certain structure outlined
in the ABI spec. Here is the PR for this:

https://github.com/ARM-software/abi-aa/pull/320

> 3. there's a new static inline function (fweimer's code pasted as-is
> here, but note that there's a missing multiplication because the
> "size" field is in bytes, not array elements):
> 
> __ifunc_hwcap (const unsigned long int *__arg, unsigned long int __index)
> {
>   return __index - 1 < __arg[0] ? __arg[__index] : 0;
> }

I agree we should have such a function.

> 4. new doc comments explaining that everyone should [optionally,
> unless/until they actually need hwcap3+]:

I was going to add a section on this to the Glibc manual, but I'm not sure
where to put it. There isn't any section dedicated to ifunc resolvers.


> 5. we probably do need a #define that makes it clear that
> __ifunc_hwcap() exists (since there's no __has_function :-( ).

I'm adding macros that could be used for this.

Thanks,
Yury