[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