public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: adhemerval.zanella@linaro.org
Cc: ishitatsuyuki@gmail.com, libc-alpha@sourceware.org,
	rui314@gmail.com, ruiu@bluewhale.systems, schwab@linux-m68k.org,
	Andrew Waterman <andrew@sifive.com>,
	fweimer@redhat.com
Subject: Re: [PATCH v6 3/3] RISC-V: Implement TLS Descriptors.
Date: Tue, 02 Apr 2024 09:37:22 -0700 (PDT)	[thread overview]
Message-ID: <mhng-4541c7de-ed58-446e-b23e-2005e3145766@palmer-ri-x1c9> (raw)
In-Reply-To: <dc415343-c570-4167-8838-8c7a067c8b4d@linaro.org>

On Tue, 02 Apr 2024 08:32:59 PDT (-0700), adhemerval.zanella@linaro.org wrote:
>
>
> On 02/04/24 12:25, Palmer Dabbelt wrote:
>
>>
>>> 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.
>
> Indeed I meant 'profiles' here and my understanding was that something like
> RVA22U64 as base would simplify things a bit (at least with the possible
> testing/checking the multiple build permutations that using optional
> extensions would incur).

If we could get all the HW vendors to agree to something it wouldn't 
hurt, but trying to move to one of the newer profiles would mean 
dropping support for existing hardware (and thus breaking users who are 
stuck with it, a lot of this newer hardware seems pretty buggy right 
now).  Vendors seem to be implementing stuff that's close to the 
profiles, but it's still a bit of a mess -- plus we end up with the 
whole vendor self-certification issue, which means it's really hard to 
tell what HW actually does from the marketing material.

I'm hoping that something like Android will help here, as there we'll 
have people who are actually shipping systems defining the compatibility 
requirements.  With any luck that will start getting these issues at 
least understood over at RVI, but it's still going to be a long process 
before we get stuff sane.

  reply	other threads:[~2024-04-02 16:37 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
2024-04-02 15:32             ` Adhemerval Zanella Netto
2024-04-02 16:37               ` Palmer Dabbelt [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=mhng-4541c7de-ed58-446e-b23e-2005e3145766@palmer-ri-x1c9 \
    --to=palmer@dabbelt.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=andrew@sifive.com \
    --cc=fweimer@redhat.com \
    --cc=ishitatsuyuki@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=rui314@gmail.com \
    --cc=ruiu@bluewhale.systems \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).