[PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC.

[Jim Wilson]

On Wed, Aug 11, 2021 at 3:13 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:

> I'm trying to stay away from the foundation stuff these days, but from
> reading that spec it doesn't look like the variant CC has anything to do
> specifically with the V extension but instead is about allowing for
> arbitrary calling conventions for X and F registers as well.  Handling
> non-standard X-register calling conventions is really a whole different
> beast than handling non-standard F or V register calling conventions.
> It's not crazy to allow for these, but lumping them all into a single
> bit just makes this unnecessarily difficult.
>

This is the exact same solution that the aarch64 port uses.  We aren't
inventing anything new here.

The intent is not to support arbitrary calling conventions.  The intent is
that we will have two official calling conventions once we add vector
support, one that uses vector registers and one
that doesn't.  Most code will use the non-vector register ABI, and we
expect glibc will be compiled this way for maximum portability.  But we
will need to support the second ABI that does have vector registers, and
hence we only need a single bit for that at this time.

If you aren't willing to participate in the official ABI committee, then
you should at least be willing to accept their decisions.

and would still allow us to have lazy binding for the variants.  At a
> bare minimum we can support arbitrary V register calling conventions for
> free until we start using the V registers in glibc, which is likely
> quite a way off.
>

We already have patches to use V registers in glibc, and we are already
using them.  We already upstreamed the ifunc support for binutils and glibc
required to use vector instructions.  We use them for mem* and str*
routines.  Adopting the position that the resolver isn't allowed to call
any mem* or str* functions is unreasonable.  Hence the need for this patch.

Jim