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 B7E0A3858422 for ; Thu, 22 Sep 2022 09:44:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7E0A3858422 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 746AC300089; Thu, 22 Sep 2022 09:44:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1663839886; bh=NCzLogWqAC2KS9tuqagLCNK6ii5s794zOZUfKZtRvec=; h=Message-ID:Date:Mime-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kMhLrHsg+yyZfUaAxW6cCxmEGUs1GFhKDuRDk6ppPi3HPnFL6IliAFdEloU4H8okd QVqCiCevNcITSKYxce2C1jnJwxtcxE0S/dQtKzaW02aMU1mBGpRJ7Nj/aUDCrzWVji s3LcRZph2Mx4R1UVsXfCfyKR0l14iM1lCIBj5HpY= Message-ID: Date: Thu, 22 Sep 2022 18:44:43 +0900 Mime-Version: 1.0 Subject: Re: [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs Content-Language: en-US To: Nelson Chu Cc: Kito Cheng , Palmer Dabbelt , Andrew Waterman , 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 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 > >> 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 >> >