[PATCH v2] aarch64: add support or hwcap3,4

Yury Khrustalev yury.khrustalev@arm.com
Tue Apr 22 12:52:02 GMT 2025


Hi everyone,

I posted v3:
https://inbox.sourceware.org/libc-alpha/20250422124322.3056938-1-yury.khrustalev@arm.com/

On Tue, Apr 08, 2025 at 10:57:13AM -0300, Adhemerval Zanella Netto wrote:
> 
> 
> On 08/04/25 10:22, enh wrote:
> > On Tue, Apr 8, 2025 at 8:11 AM Adhemerval Zanella Netto
> > <adhemerval.zanella@linaro.org> wrote:
> >>
> >>
> >>
> >> On 08/04/25 08:02, Yury Khrustalev wrote:
> >>> Should we consider cases like below?
> > 
> ...
> If source compatibility is really required, I would prefer the union
> type instead of a new bit flags instead of a new function prototype.

Yes, I think it matters. There is existing code that uses the _hwcap and
_hwcap2 fields. I added union in v3.

>   struct __ifunc_arg_t
>   {
>     unsigned long _size;
>     union {
>       struct {
>         unsigned long _hwcap;
>         unsigned long _hwcap2;
>       } _hwcap_struct;
>      unsigned long _hwcap_array[_IFUNC_HWCAP_MAX];
>     } _hwcap_union;
>   #define _hwcap  _hwcap_union._hwcap_array[0]
>   #define _hwcap2 _hwcap_union._hwcap_array[1]
>   #define _hwcap3 _hwcap_union._hwcap_array[2]
>   #define _hwcap4 _hwcap_union._hwcap_array[3]

If we add these macros, then we don't need union at all I guess?
However, "_hwcap" is quite generic and defining such macros may
cause some unexpected conflicts during compilation, so I'd rather
not define these macros.

> I don't think strict aliasing would be a problem on ifunc resolvers.

Great!

Kind regards,
Yury



More information about the Libc-alpha mailing list