From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Cc: libc-alpha@sourceware.org, Rui Ueyama <rui314@gmail.com>,
Rui Ueyama <ruiu@bluewhale.systems>,
schwab@linux-m68k.org, andrew@sifive.com,
Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH v6 3/3] RISC-V: Implement TLS Descriptors.
Date: Tue, 2 Apr 2024 10:35:21 -0300 [thread overview]
Message-ID: <1d86a4d8-2fb9-42b1-90eb-4c9fbe0c0729@linaro.org> (raw)
In-Reply-To: <714A258E-657E-4D87-8CF1-213F03F27AC6@gmail.com>
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.
>
> 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.
>
> I suppose the softfp path will remain the same since not all softfp environment will support hwprobe per the reasoning.
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
I am not sure whether RISC-V maintainer would like to move to profilers
or would keep this extensions composability manner.
>
> Tatsuyuki.
next prev parent reply other threads:[~2024-04-02 13:35 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 [this message]
2024-04-02 15:25 ` Palmer Dabbelt
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:
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=1d86a4d8-2fb9-42b1-90eb-4c9fbe0c0729@linaro.org \
--to=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).