Re: [Qemu-riscv] [Qemu-devel] [PATCH 1/5 v2] RISC-V: Add 32-bit gdb xml files.

[Jim Wilson]

On Sat, Dec 29, 2018 at 2:20 PM Richard Henderson
<address@hidden> wrote:
> On 12/29/18 9:07 AM, Jim Wilson wrote:
> Don't the csr's vary between priv-1.9.1 and priv-1.10?

There are a few csr's that disappear in 1.10, but there is no known
hardware that implements them.  There are a few csr's new in 1.10, but
I don't know of any 1.9.1 systems that can run the software that
requires the new registers.  There are a few that change name; the
toolchain supports both the old and new names.  On the toolchain side,
currently, none of the tools care about the privilege spec version.
And the linux kernel doesn't care about the priv spec version either.
This will eventually have to change, maybe with 1.11, but so far it
hasn't been an issue with any software I've seen.

qemu has an option to specify the priv spec version.  But looking at
the csr's, this affects two of the registers that disappeared, which
were never implemented in hardware, and aren't supported by gdb.  This
also affects a few registers that have new fields in 1.10, but gdb
doesn't know about those internal register fields, so this doesn't
affect gdb either.

> I wonder if it would be better to auto-generate these, via the
> gdb_get_dynamic_xml hook.  That way you don't need near identical copies for
> 32-bit vs 64-bit.

I haven't tried looking at this, but I don't see a convenient list of
implemented csr's.  This list would be every csr that the
csr_read_helper function in target/riscv/op_helper.c supports  That
function requires some machine state that includes the register
values, so it doesn't look convenient to use, unless we add more
hackery to it.

Long term, it would be useful to have target specific csr register
lists.  Most csr's are optional, and most hardware only implements a
subset of them.  This is somewhat orthogonal to what I'm trying to do
here, but this would require a list of supported csr's in the target
hardware file, then this would have to be fed back into
csr_read_helper somehow, and then we could also use this to generate
an appropriate xml csr register file for that target for use with gdb.
Openocd already does something like this for a few supported targets.

Jim