Re: [PATCH v6 3/3] RISC-V: Implement TLS Descriptors.

[Palmer Dabbelt <palmer@dabbelt.com>]

On Tue, 02 Apr 2024 06:35:21 PDT (-0700), adhemerval.zanella@linaro.org wrote:
>
>
> On 02/04/24 00:36, Tatsuyuki Ishi wrote:
>>> On Apr 2, 2024, at 4:29, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote:
>>>
>>> Maybe a better option, now that glibc has internally riscv_hwprobe
>>> support and that RVV is only support for 6.5, to use instead of adding
>>> another ABI variant.

We might end up with a new ABI variant for the hard-vector calling 
convention (ie, passing vector registers in arguments)
at some point, but that's a little way off.  We don't even support it as 
a base ABI in GCC yet, and it's too late to do something like that for 
14.

Either way we'd need to make tlsdesc work on systems with the V 
extension and the soft-vector ABI, which means dynamically probing for 
it.

>> Does this mean that it can be assumed that RVV code will only be executed on an environment that also supports riscv_hwprobe? In that case, I agree that we should switch the RVV path to use feature detection.
>
> Unless RVV support is backported without backporting riscv_hwprobe as well,
> although I expected that RISC-V maintainer would avoid it because the
> whole riscv_hwprobe is to enable runtime selection for RVV and alike
> features.

Ya, that seems like a way to just make headaches.  V is particularly 
tricky because it has use-visible state and thus everything needs to 
know about it to work.

There's also a prctl() for enabling/disabling the V extension at 
runtime that we'll need to check, but that's in the same spot.

>> I suppose the softfp path will remain the same since not all softfp environment will support hwprobe per the reasoning.

hwprobe doesn't change anything about the soft float ABI, that needs to 
be linked with compatible objects in order to function correctly.  
That's the same spot we'd end up in for the hard-vector ABI, if we added 
one.

> I take that softfp is a de-facto ABI for RISC-V, at least this what we
> have on build-many-glibcs.py:
>
>   riscv64-linux-gnu-rv64imac-lp64
>   riscv64-linux-gnu-rv64imafdc-lp64
>   riscv64-linux-gnu-rv64imafdc-lp64d

Ya, we have soft-float and double-float ABIs in glibc.  There's also a 
single-float ABI in GCC, but we decided not to add that to glibc to 
avoid the complexity.

> I am not sure whether RISC-V maintainer would like to move to profilers
> or would keep this extensions composability manner.

What do you mean by "move to profilers"?  "move to profiles"?

We have the profiles in RISC-V, but they don't really fix anything here: 
there's a ton of them, they still have various optional extensions, and 
the HW support is all over the place (we don't even have compatibility 
guarantees with individual extensions, for example).

So I think for just sticking to the current base ABIs is the way to go.  
Maybe at some point HW vendors will start shipping systems that are 
compatible with some common extension set and we can promote that to a 
new base ABI, but we're a way off from that happening.

>
>>
>> Tatsuyuki.