[PATCH v4 3/3] aarch64: helper function to access hwcap elements in ifunc resolver

[enh]

On Fri, Apr 25, 2025 at 11:59 AM Yury Khrustalev
<yury.khrustalev@arm.com> wrote:
>
> On Fri, Apr 25, 2025 at 11:39:07AM -0400, enh wrote:
> > On Fri, Apr 25, 2025 at 11:25 AM Florian Weimer <fweimer@redhat.com> wrote:
> > >
> > > > On Fri, Apr 25, 2025 at 7:35 AM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
> > > >>
> > > >> +/* ID values for the helper function below.  */
> > > >> +enum
> > > >> +{
> > > >> +  __IFUNC_HWCAP = 1,
> > > >> +  __IFUNC_HWCAP2,
> > > >> +  __IFUNC_HWCAP3,
> > > >> +  __IFUNC_HWCAP4,
> > > >> +};
> > > >
> > > > i get why you're adding this enum -- so you can say __IFUNC_HWCAP
> > > > rather than 1, which isn't as clear as 2 and later -- but this seems
> > > > to partly defeat the purpose of switching to the function. one of the
> > > > beauties of the function is that you never need to touch this header
> > > > again. personally i think i'd rather live with 1 than undo that?
>
> You don't need to use enum. I added it mostly to indicate the mapping between
> integer IDs and HWCAP elements. It should help understand why you get 0 from
> this function when you use ID 0 (perhaps hoping to get AT_HWCAP :)).
>
> There may be other reasons not to use this helper function at all, e.g. if
> if need to check several bits, calling it several times would duplicate
> checks against _size which may be undesirable in an ifunc resolver.

dude, if your compiler's that weak, clang and gcc are available for
the low low price of "free"...

> > > HWCAP is already passed as the first argument of the IFUNC resolver, so
> > > I don't think people would write
> > >
> > >   __ifunc_hwcap (1, hwcap, args)
> > >
> > > to get this value.  Wouldn't they just use hwcap directly?
> >
> > /me checks the code i have indexed...
> >
> > llvm/compiler-rt and partition alloc do. libgcc/libatomic do. the only
> > exception i found was bionic, funnily enough :-)
>
> The way I read the ABI spec: if the _IFUNC_ARG_HWCAP bit is set in the 1s
> parameter, the correct value of AT_HWCAP is in arg[1]. But in practice,
> because the _IFUNC_ARG_HWCAP bit is reserved (so it cannot be used for
> any HW feature), it doesn't make any difference and both values can be
> used to check feature bits.
>
> But I think it's better to provide consistent interface (so support all
> HWCAP fields).

i think fweimer's point was "if you don't like the oddity of saying 1
for hwcap, just use the separate hwcap argument, which you can call
whatever you like", which -- given my bias -- i read as weak support
for "we don't need an enum" :-)

> Thanks,
> Yury
>