[PATCH v6 1/2] aarch64: add support for hwcap3,4

[Adhemerval Zanella Netto]

On 20/05/25 12:36, enh wrote:
> On Mon, May 19, 2025 at 9:28 AM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
>>
>> On Tue, May 13, 2025 at 10:50:54AM -0400, enh wrote:
>>> On Tue, May 13, 2025 at 10:13 AM Yury Khrustalev
>>> <yury.khrustalev@arm.com> wrote:
>>>>
>>>> Add basic support for hwcap3 and hwcap4 in dynamic loader and
>>>> ifunc resolvers.
>>>> ...
>>>> -/* Second argument to an ifunc resolver.  */
>>>>  struct __ifunc_arg_t
>>>>  {
>>>> -  unsigned long _size; /* Size of the struct, so it can grow.  */
>>>> +  unsigned long _size;    /* Size of the struct, so it can grow.  */
>>>>    unsigned long _hwcap;
>>>> -  unsigned long _hwcap2;
>>>> +  unsigned long _hwcap2;  /* End of 1st published struct.  */
>>>> +  unsigned long _hwcap3;
>>>> +  unsigned long _hwcap4;  /* End of 2nd published struct.  */
>>>
>>> (i'm ambivalent about adding the extra named fields here, because i
>>> think it discourages folks from switching to the helper function ---
>>> and if you've got a header new enough for the extra named fields, you
>>> also have the helper function. but if glibc adds these, i'll add them
>>> to bionic too, for source compatibility.)
>>>
>>
>> I think it's better to be consistent here. We already have two fields, and
>> if we don't add new once, then this struct will be forever incomplete, and
>> I think this will look somewhat confusing.
> 
> well, that's the inherent problem with this struct --- "it will be
> forever incomplete". which is why it's deprecated. (and why my doc
> comments in the bionic version of this patch say "don't use this".)
> 
>>>>  };
>>>>
>>>> +#define _IFUNC_ARG_SIZE_VER0 24 /* sizeof 1st published struct */
>>>> +#define _IFUNC_ARG_SIZE_VER1 40 /* sizeof 2nd published struct */
>>>
>>> (but i _won't_ add these to bionic --- i can't think of any _good_ use
>>> for these, only mischief.)
>>
>> Glibc does this for internal static asserts that are handy for the future
>> programmers who make a change and may forget to update other related parts
>> (see for example struct clone_args). So, I thought it makes sense to have
>> these macros here too.
> 
> glibc doesn't need to export those numbers though --- they can just be
> in the test itself.

Indeed, since they are exported in a private namespace anyway.  These do
not seem to be defined by the recent ABI addition [1], so I think we should
make them private as well.

[1] https://github.com/ARM-software/abi-aa/commit/4741495ca2024d551d3f1a0450cb971ef0b347d3