> > This API is intended to provide the capability to query minimal common
> > available extensions on the system.
> >
> > Proposal in riscv-c-api-doc:
> > https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74
>
> That's not merged, but I'm not sure what the rules are on stability for
> the C API doc.
The general rule is wait until achieving consensus between the GNU and
LLVM community,
you may know we (sifive folks) still have some discussion with Philip
Reames, so that's why
> > +static void __init_riscv_features_bits_linux ()
> > +{
> > + struct riscv_hwprobe hwprobes[] = {
> > + {RISCV_HWPROBE_KEY_BASE_BEHAVIOR, 0},
> > + {RISCV_HWPROBE_KEY_IMA_EXT_0, 0},
> > + {RISCV_HWPROBE_KEY_MVENDORID, 0},
> > + };
> > +
> > + long rv = syscall_5_args (__NR_riscv_hwprobe, (long)&hwprobes,
> > + sizeof (hwprobes) / sizeof (hwprobes[0]), 0,
> > + 0, 0);
>
> We were talking about this on the patchwork call, but went on to
> something else. I was still kind of curious as to how this worked, and
> it's because this is just calling the syscall directly. I think that's
> OK, as we're not resolving the hwprobe libc function. It means we lose
> the caching from the VDSO, but we're caching again here so maybe that
> doesn't really matter -- we're just caching twice, but it's not like
> the performance is going to be worse than Arm/Intel (just a bit clunky).
>
> We did come back to it in the patchwork call, though, and were a bit
> worried about those symbol lookups. So the conclusion was to put
> together a test to make sure we can actually look up these symbols from
> IFUNCs.
This function may also be used by __builtin_cpu_init, so IFUNC's parameter
is not available for that situation.
>
> > +
> > + if (rv)
> > + return;
>
> Don't we need to also zero out the extension list when the syscalls
> fails?
We don't really need that since global variables should be zero-initialized
by default :)
and following zero out logic is only used for local variable copy only.
> > +void __init_riscv_feature_bits ()
> > +{
> > + if (__init)
> > + return;
> > +
> > +#ifdef __linux
> > + __init_riscv_features_bits_linux ();
>
> Just thinking a bit here: if we have an ABI where
> __init_riscv_feature_bits() takes an argument that's either 0 (ie, "do
> the syscall") or the pre-resolved VDSO function then we can avoid going
> into the kernel
Yeah, sounds like a reasonable way, and call that a platform specific argument.
