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

[Palmer Dabbelt <palmer@dabbelt.com>]

On Wed, 11 Aug 2021 16:00:31 PDT (-0700), Jim Wilson wrote:
> 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.

All I'm trying to do here is point out that the ABI you've defined has 
some much broader costs to implement than the features you're 
advertising you want to use it for.  If this is the ABI you want that's 
fine, I don't really care, just go make it part of the official psABI 
spec and we'll get on with our lives.

> 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