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

[Palmer Dabbelt <palmer@dabbelt.com>]

On Wed, 11 Aug 2021 16:32:38 PDT (-0700), jrtc27@jrtc27.com wrote:
> On 12 Aug 2021, at 00:21, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> 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.
>
> As I explained in my reply, in practice the solution for the vector calling convention specifically ends up being the solution for the more general problem, and so there are no such broader costs beyond the edge-case you identified that’s just an underspecification issue.
>
> Regarding making it a part of the psABI spec, it has already been approved by all relevant parties, it has just been waiting on a proof-of-concept, or better, patch for either glibc or FreeBSD, which this provides, since for important features like this our policy is to not merge additions to the psABI spec until patches exist to prove its viability.

OK, no problem.  Next time just please make it clear when you guys send 
something out for review that all discussion here is irrelevant, because 
it'll save us the time.

IIUC the ABI patch still isn't merged, which is what makes it actually 
official.  I'll take this when it lands.

>
> Jess
>
>>> 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