Re: [PATCH] RISC-V: Correct legacy misa register number.

[Jim Wilson <jimw at sifive dot com>]

On Tue, Jul 3, 2018 at 5:35 PM, Palmer Dabbelt <palmer@sifive.com> wrote:
> FWIW, there's no legacy RISC-V hardware that can run a native GDB.  Thus the
> only mechanism to access this would be via a JTAG debugger, and there's no
> ABI spec for those.
>
> Is there even a reason to have a legacy MISA CSR exposed to GDB?  I feel
> like we can just handle this in the JTAG debugger and keep this oddity from
> slipping into an ABI.
>
> I'm adding Tim as he might have more context.

This is code that gets used for both linux native and embedded cross.
So the fact that there is no legacy hardware that can run linux isn't
relevant.

Gdb is trying to read misa to discover what features exist on the
target, C, F, D, etc.  It first tries to read the 1.10 misa, and if
that fails, it then tries to read the 1.9 misa.  If the 1.9 misa
fails, then you get a cryptic error about a missing register.  But the
priv spec says that misa should always exist and always be readable,
so I think you can only get the cryptic error from the broken linux
support in github riscv/riscv-binutils-gdb.  If the misa read returns
0, which is allowed by the priv spec, then gdb looks at the program
elf header flags, and assumes the target hardware matches the ELF
file.

My linux support for now just returns 0, but in the future it might be
nice to have ptrace support for reading misa.  This would only need to
support the 1.10 misa.

As far as I know, the legacy misa support should remain.  But I don't
know how the OpenOCD support works.  I suppose you want to make
OpenOCD try reading both register numbers if we ask for the 1.10 misa?
 I don't see the benefit of that.  There isn't really any ABI exposure
here.  It is just a few lines of code in gdb to try to read misa,
falling back to the old number if the new number doesn't work.

Jim