public inbox for
 help / color / mirror / Atom feed
From: Palmer Dabbelt <>
	Andrew Waterman <>,
Subject: Re: [PATCH v6 3/3] RISC-V: Implement TLS Descriptors.
Date: Tue, 02 Apr 2024 08:25:11 -0700 (PDT)	[thread overview]
Message-ID: <mhng-efda4c64-2743-4012-9406-2828951a0844@palmer-ri-x1c9> (raw)
In-Reply-To: <>

On Tue, 02 Apr 2024 06:35:21 PDT (-0700), wrote:
> On 02/04/24 00:36, Tatsuyuki Ishi wrote:
>>> On Apr 2, 2024, at 4:29, Adhemerval Zanella Netto <> 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 

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 

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

> I take that softfp is a de-facto ABI for RISC-V, at least this what we
> have on
>   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.

  reply	other threads:[~2024-04-02 15:25 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 18:12 [PATCH] " Tatsuyuki Ishi
2023-08-17 18:35 ` Andreas Schwab
2023-09-08 10:55 ` [PATCH v2] " Tatsuyuki Ishi
2023-09-13 17:26 ` [PATCH v3] " Tatsuyuki Ishi
2023-09-13 19:14   ` Adhemerval Zanella Netto
2023-09-14  8:39     ` Tatsuyuki Ishi
2023-09-14 12:09       ` Adhemerval Zanella Netto
2024-01-27  2:22         ` Fangrui Song
2023-09-13 19:07 ` [PATCH] " Andrew Waterman
2023-09-14  8:40 ` [PATCH v4 0/3] " Tatsuyuki Ishi
2023-09-14  8:40   ` [PATCH v4 1/3] RISC-V: Add include guard for dl-tls.h Tatsuyuki Ishi
2024-01-27  1:14     ` Fangrui Song
2023-09-14  8:40   ` [PATCH v4 2/3] RISC-V: Add TLSDESC reloc definitions Tatsuyuki Ishi
2024-01-27  1:12     ` Fangrui Song
2023-09-14  8:40   ` [PATCH v4 3/3] RISC-V: Implement TLS Descriptors Tatsuyuki Ishi
2023-11-23 11:39     ` Florian Weimer
2024-03-29  5:55 ` [PATCH v5 0/3] " Tatsuyuki Ishi
2024-03-29  5:55   ` [PATCH v5 1/3] RISC-V: Add include guard for dl-tls.h Tatsuyuki Ishi
2024-03-29  5:55   ` [PATCH v5 2/3] RISC-V: Add TLSDESC reloc definitions Tatsuyuki Ishi
2024-03-29  5:55   ` [PATCH v5 3/3] RISC-V: Implement TLS Descriptors Tatsuyuki Ishi
2024-03-29  6:18 ` [PATCH v6 0/3] " Tatsuyuki Ishi
2024-03-29  6:18   ` [PATCH v6 1/3] RISC-V: Add include guard for dl-tls.h Tatsuyuki Ishi
2024-04-03 11:48     ` Adhemerval Zanella Netto
2024-03-29  6:18   ` [PATCH v6 2/3] RISC-V: Add TLSDESC reloc definitions Tatsuyuki Ishi
2024-04-03  5:10     ` Fangrui Song
2024-04-03  8:03     ` Andreas Schwab
2024-03-29  6:18   ` [PATCH v6 3/3] RISC-V: Implement TLS Descriptors Tatsuyuki Ishi
2024-04-01 13:23     ` Florian Weimer
2024-04-01 19:29     ` Adhemerval Zanella Netto
2024-04-02  3:36       ` Tatsuyuki Ishi
2024-04-02 13:35         ` Adhemerval Zanella Netto
2024-04-02 15:25           ` Palmer Dabbelt [this message]
2024-04-02 15:32             ` Adhemerval Zanella Netto
2024-04-02 16:37               ` Palmer Dabbelt
2024-04-30 17:05   ` [PATCH v6 0/3] " Palmer Dabbelt
2024-04-30 18:33     ` Adhemerval Zanella Netto
2024-05-01  1:36       ` Tatsuyuki Ishi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mhng-efda4c64-2743-4012-9406-2828951a0844@palmer-ri-x1c9 \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).