From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id B2F4A3858D1E for ; Fri, 30 Sep 2022 15:44:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B2F4A3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 26E48300089 for ; Fri, 30 Sep 2022 15:44:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1664552691; bh=+MwtdptzSElzYvRHzkXo5XVtb/JDRGr4q/eIrVYD9hc=; h=Message-ID:Date:Mime-Version:Subject:To:References:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JdZPAHLp8Bh4A6ZbnZq2FgGDCzNiqhBA2Dqfa9nlPaV4laBoL196iwILjAk2k2OV2 9AKAqOpFff2ykWBokuDAW5lcsM0F+aMBh8nlJebfRNzmhV8tN4DkSRzJbr5Q5QwONt sUNLcZ/NlfYPv/1OQaQ6rhY51Ff0HjGLDA0lIRxI= Message-ID: <05a8d99a-b6cd-3ea2-35b8-0dc36dbef743@irq.a4lg.com> Date: Sat, 1 Oct 2022 00:44:50 +0900 Mime-Version: 1.0 Subject: Re: [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs Content-Language: en-US To: binutils@sourceware.org References: From: Tsukasa OI In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022/09/22 18:44, Tsukasa OI via Binutils wrote: > On 2022/09/22 17:48, Nelson Chu wrote: >> On Thu, Sep 22, 2022 at 3:59 PM Tsukasa OI wrote: >>> >>> Currently, GNU Binutils does not support following privileged extensions: >>> >>> - 'Smepmp' >>> - 'Svnapot' >>> - 'Svpbmt' >>> >>> as they do not provide new CSRs or new instructions ('Smepmp' extends the >>> privileged architecture CSRs but does not define the CSR itself). However, >>> adding them might be useful as we no longer have to "filter" ISA strings >>> just for toolchains (if full ISA string is given by a vendor, we can >>> straightly use it). >> >> OKay. >> >> Nelson > > Understood. I'm going to push this patch in a week if there's no other > comments. But until then, I'll wait for other opinions. > > Thanks, > Tsukasa Committed since there's no objections here. Thanks, Tsukasa > >> >>> And there's a fact that supports this theory: there's already an >>> (unprivileged) extension which does not provide CSRs or instructions (but >>> only an architectural guarantee): 'Zkt' (constant timing guarantee for >>> certain subset of RISC-V instructions). >>> >>> This simple patchset simply adds three privileged extensions listed above. >>> >>> bfd/ChangeLog: >>> >>> * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp', >>> 'Svnapot' and 'Svpbmt' extensions. >>> --- >>> bfd/elfxx-riscv.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c >>> index 7eda177bd6e..bbc30c9afc2 100644 >>> --- a/bfd/elfxx-riscv.c >>> +++ b/bfd/elfxx-riscv.c >>> @@ -1210,10 +1210,13 @@ static struct riscv_supported_ext riscv_supported_std_z_ext[] = >>> >>> static struct riscv_supported_ext riscv_supported_std_s_ext[] = >>> { >>> + {"smepmp", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, >>> {"smstateen", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, >>> {"sscofpmf", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, >>> {"sstc", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, >>> {"svinval", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, >>> + {"svnapot", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, >>> + {"svpbmt", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, >>> {NULL, 0, 0, 0, 0} >>> }; >>> >>> -- >>> 2.34.1 >>> >> >