riscv_fix_csr_imply_on_priv

RISC-V: Workaround for CSR implications to the Privileged Architecture

• Status: Merged for Binutils 2.40
• Branch: riscv-fix-csr-imply-on-priv
• Tracking PR: #49 (view Pull Request and Diff)
• Mailing List:
  • RFC PATCH v1 (2022-10-08)

Based On

• RISC-V: Fix CSR accessibility and implications
  This is a subset.

Issue Solved

Quoting RISC-V Instruction Set Manual Volume II: Privileged Architecture,

Chapter 2: Control and Status Registers (CSRs)

...

The privileged architecture requires the Zicsr extension; which other privileged instructions are required depends on the privileged-architecture feature set.

So, if we use the privileged architecture, we should imply Zicsr. You may wonder why I'm insisting so when seemingly different terms "depend" and "imply" are used. There's two reasons for that.

1. We already handle those terms "depend" and "imply" equivalently
   (like in F → Zicsr and D → F)
2. Quoting Andrew (https://github.com/riscv/riscv-isa-manual/pull/838#issuecomment-1107473631),

   In this context, I view “require” and “imply” as equivalent, meaning that e.g. RV32IV and RV32IDV and RV32IFDV are all equivalent.

The problem here is, we don't have a "direct" way to represent dependency to the privileged architecture itself.

As a workaround, we should add implications from privileged extensions that either add new CSRs, extend existing CSRs or depends on using CSRs. For ISA strings with those extensions, we can safely assume that we depend on the privileged architecture (and indirectly, the Zicsr extension).

This patch adds implications for existing privileged extensions:

• H
• Smstateen
• Sscofpmf
• Sstc
• Smepmp

Related Discussion

• https://sourceware.org/pipermail/binutils/2022-October/123559.html