[PATCH v1 1/2] RISC-V: move zicsr/zifencei spec version check to Kconfig

[Palmer Dabbelt]

On Tue, 07 Mar 2023 11:14:54 PST (-0800), Conor Dooley wrote:
> On Mon, Mar 06, 2023 at 03:52:27PM -0800, Palmer Dabbelt wrote:
>> On Fri, 24 Feb 2023 09:00:09 PST (-0800), Conor Dooley wrote:
>> > On Fri, Feb 24, 2023 at 09:37:28AM -0700, Nathan Chancellor wrote:
>> > > On Thu, Feb 23, 2023 at 10:05:45PM +0000, Conor Dooley wrote:
>> > 
>> > > > ---
>> > > >  arch/riscv/Kconfig  | 10 ++++++++++
>> > > >  arch/riscv/Makefile |  5 +----
>> > > >  2 files changed, 11 insertions(+), 4 deletions(-)
>> > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> > > > index cebf0c5f8824..4eb0ef8314b3 100644
>> > > > --- a/arch/riscv/Kconfig
>> > > > +++ b/arch/riscv/Kconfig
>> > > > @@ -288,6 +288,16 @@ config ARCH_RV64I
>> > > >  >  endchoice
>> > > >  > +config TOOLCHAIN_NEEDS_SPEC_20191213
>> > > 
>> > > This symbol's name is a little confusing to me, how does the toolchain
>> > > need spec version 20191213. Maybe 'SPEC_20191213' should be something
>> > > like 'EXPLICIT_ZICSR_ZIFENCEI'? Otherwise, maybe it should be something
>> > > like 'TOOLCHAIN_HAS_DEFAULT_SPEC_20191213'? Sorry for the bikeshed but I
>> > > think most Kconfig symbols should be self describing.
>> > 
>> > Yah I can do that. I actually had this as the DEFAULT_SPEC variant
>> > before and changed it - I'll switch it to the EXPLICIT one.
>> > Thanks for taking a look Nathan :)
>> 
>> Another option here would be to use the `-misa-spec` argument for GCC, to
>> make it match LLVM's spec version.
>
> I'm not entirely sure what you're getting at.
> You're the toolchain guy, but my understanding was that gas and gcc have
> that option, but not ld, which rules out my initial interpretation. 
> Are you suggesting that we always pass -misa-spec=<pre-zicsr_zifencei> to
> gcc so that we are using the same misa-spec for both gnu and llvm
> toolchain bits?

Pretty much, I think just $(cc-option -misa-spec=2.2) should do it.  
That should also cover older GCC versions, as we added the argument long 
before we changed the default.

> My instinctive thought was that that is kinda fragile to things
> misaligning between gcc/llvm, but given I seem to end up looking at this
> every month, we're really fragile to changes in either camp anyway...

Pretty much, but in this case we're essentially just disabling a form of 
change by sticking to an ISA spec version.

> I can go spin an alternative v2 of this up if I have understood you
> correctly.

Thanks

>
> Thanks,
> Conor.