[PATCH v11 4/7] riscv: Add __riscv_hwprobe pointer to ifunc calls

[Jessica Clarke]

O Wed, Jan 10, 2024 at 12:51:37PM -0800, Evan Green wrote:
> The new __riscv_hwprobe() function is designed to be used by ifunc
> selector functions. This presents a challenge for applications and
> libraries, as ifunc selectors are invoked before all relocations have
> been performed, so an external call to __riscv_hwprobe() from an ifunc
> selector won't work. To address this, pass a pointer to the
> __riscv_hwprobe() function into ifunc selectors as the second
> argument (alongside dl_hwcap, which was already being passed).
> 
> Include a typedef as well for convenience, so that ifunc users don't
> have to go through contortions to call this routine. Users will need to
> remember to check the second argument for NULL, to account for older
> glibcs that don't pass the function.
> 
> Signed-off-by: Evan Green <evan@rivosinc.com>

I still don't understand why you need to do this rather than just alter
relocation processing such that ifunc resolvers are called after other
relocations in the object have been processed, like FreeBSD, which would
obviate the need for the function pointer and allow any non-ifunced
function (that itself does not transitively call an ifunc not guaranteed
to have been resolved already), including __riscv_hwprobe itself, to be
called from the resolver. This avoids tying ifunc resolvers to a
specific interface for querying extensions, instead giving a general
solution that seems like a useful thing to have even outside of RISC-V.

I'll note that telling other OSes they should just pass in a dummy +1
value is a non-solution; other OSes don't want to have to add a
meaningless parameter for a Linux-specific interface.

So, please, I urge you to reconsider this interface before it forever
gets baked ino the ABI and the parameter can never be used for anything
else. It may fit your needs, but I do not think it is a good idea for
the wider ecosystem.

Jess