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

Yury Khrustalev yury.khrustalev@arm.com
Tue Apr 8 11:02:06 GMT 2025


Should we consider cases like below?

After adding the new fields `_hwcap3` and `_hwcap4`, there will be
two versions of the `__ifunc_arg_t` type depending on which header
is used during compilation of the code for a resolver function with
no compile-time way to decern between these versions.

Those resolvers that want to use the new fields (naturally, guarded
by the runtime checks based on the `_size` field), will no longer
compile with older headers because they are missing the `_hwcap3,4`
fields.

Ideally, __ifunc_arg_t should've been defined as

struct __ifunc_arg_t
{
  unsigned long _size;
  unsigned long _hwcap_array[N];
}

where N could be increased over time as needed.

To retain backward compatibility with existing code, we could use a
union:


struct __ifunc_arg_t
{
  unsigned long _size;
  union {
    struct {
      unsigned long _hwcap;
      unsigned long _hwcap2;
    };
    unsigned long _hwcap_array[4];
  };
};

and deprecate `_hwcap` and `_hwcap2` in favour of `_hwcap_array`.


However, using `_hwcap` and `_hwcap2` may become UB when strict aliasing
rules are enforced.

Another way could be introducing macros like this:

struct __ifunc_arg_t
{
  unsigned long _size;
  unsigned long _hwcap;
  unsigned long _hwcap2;
  unsigned long _hwcap3;
  unsigned long _hwcap4;
}

#define __IFUNC_ARG_T_HWCAP3
#define __IFUNC_ARG_T_HWCAP4


In this case code that want to use the new fields when they are available,
would be able to rely on these macros.

What would be the best way forward here?

Kind regards,
Yury





More information about the Libc-alpha mailing list