Re: [PATCH v4 1/3] riscv: Add Linux hwprobe syscall support

[Evan Green <evan@rivosinc.com>]

On Fri, Jul 7, 2023 at 1:16 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Evan Green:
>
> > Add awareness and a thin wrapper function around a new Linux system call
> > that allows callers to get architecture and microarchitecture
> > information about the CPUs from the kernel. This can be used to
> > do things like dynamically choose a memcpy implementation.
>
> I missed before that you intend this for use in IFUNC resolvers, or at
> the very least I think I forgot to raise this caveat.
>
> RISC-V is not a HIDDEN_VAR_NEEDS_DYNAMIC_RELOC target, so this is not
> completely impossible, but in general, extern function calls in IFUNC
> resolvers tend to not work well.  The issue is that the GOT pointer for
> a function like __riscv_hwprobe may not have been set up when the
> dynamic linker invokes the IFUNC resolver.  There are several ways to
> solve this.  You could pass the function pointer to the IFUNC resolver
> (which may require a marker symbol and GCC changes).  Or you could a
> hidden wrapper function to libc_nonshared.a that checks if the function
> pointer to the libc implementation has been set up by a relocation and
> uses that, and falls back to a direct system call otherwise.

That makes sense, but then I'm confused about how it's been working in
my testing. What experiment should I try to see this problem in
action? An early constructor maybe?

Could I alternatively convert the implementation of the external
function into one that calls an internal helper, and then just call
the internal helper from the ifunc resolver (oh, I've reinvented a
protected symbol)? Or is that a violation of some rule?

Are there any examples of that last suggestion I can refer to?
Specifically the part about checking if the symbol has been relocated
yet or not.
-Evan