[PATCH 1/2] gdb/riscv: place unknown csrs into the correct register groups

[Andrew Burgess]

* Jim Wilson <jimw@sifive.com> [2020-11-27 14:38:44 -0800]:

> On Thu, Nov 26, 2020 at 5:09 AM Andrew Burgess <andrew.burgess@embecosm.com>
> wrote:
> 
> > To see this in action connect to QEMU, this target advertises two
> > registers dscratch and mucounteren which are unknown to GDB (these are
> > legacy CSRs).  Before this commit these registers would show up in the
> > output of:
> >
> 
> The real problem here is that no one is maintaining the RISC-V qemu gdb
> stub support.  I wrote the original version of it, but I can't single
> handedly do everything, so I'm still hoping someone else takes up
> maintenance of this.  Ideally, the qemu gdb stub should be updated when gdb
> is updated.

I know we've had discussions on this topic before, but this position
makes no sense to me.

The target description should describe the features that the TARGET
knows about, not be some super-set of registers pulled from GDB (or
anywhere else).

It should be:

  Q: Does QEMU emulate register XXXXX ?
     Yes -> Add register to target description.
     No -> Don't add register to target description.

If QEMU only offers a single configuration of RISC-V then we can get
away with a fixed XML description on the QEMU side.  If QEMU allows us
to change the configuration we're emulating then the target
description will need to be dynamically built on the QEMU side based
on which features are in use.

>                Last time I looked at qemu, all of the xml files in qemu are
> identical to the gdb ones, except for RISC-V, which was identical when I
> added it, but no longer is, because the gdb ones are changing but the qemu
> ones are not.
> 
> Anyways, I don't have any objections to this patch.  This is just a
> wishlist for someone to start maintaining qemu properly.

Indeed.  I do have a task on my list to look at this - it's just
pretty low down on my priorities right now :-/

Anyway, thanks for your feedback.

Andrew