Re: [0/1] RISC-V: Update CSR to priv 1.11.

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Jim Wilson <jimw@sifive.com> [2020-06-08 18:19:17 -0700]:

> On Mon, Jun 8, 2020 at 2:39 PM Andrew Burgess
> <andrew.burgess@embecosm.com> wrote:
> > Unless I misunderstand here, you asking why we don't use the xml
> > target descriptions?  We do.  Or we _should_ do.  Maybe it's not
> > working?  Is your target definitely sending back a description?  And
> > it definitely includes register "dscratch" ?
> 
> qemu does have xml support; I added it.  The xml register files were
> copied straight from the gdb xml files at the time I wrote the
> patches.  Unfortunately, no one is actively maintaining this code, or
> actively testing it, unless maybe you count Tom who is apparently
> testing it, so the xml files no longer match the gdb ones.

That's absolutely fine.  There's no requirement for QEMU to match
GDB[1], GDB's builtin XML files are only looked at in the case where
the target doesn't provide one[2].

>                                                             The old
> qemu version of the files does have a dscratch register because gdb
> had it at the time.  qemu does have a concept of priv spec version,
> but I doubt anyone has given any thought about how to match the xml
> files to the priv spec version.  Currently, there is a single set of
> xml files, and that isn't going to work long term.  The list of csr
> registers needs to depend on the priv spec version.

Absolutely and right now this is totally a qemu issue, it needs to
dynamically build the xml based on the type of target that's being
emulated.

We already do some of this in riscv_create_target_description, when we
build the default target description, we select 32 or 64 bit x-regs,
and optionally add 32 or 64 bit f-regs based on the features we think
the target has (which is based on the file being debugged).

In the future we might want to extend this if we do more native RISC-V
debugging, this could query the priv level and adjust the csr regs as
needed, but I don't have any targets where I could test this.

>                                                      descratch was
> added in priv spec 1.9, and was dropped in 1.11.  qemu 4.0 has 1.9.1
> and 1.10 support, so dscratch is a valid register name for priv spec
> versions supported by qemu (though qemu is dropping 1.9.1 from the
> development tree).  Anyways, dscratch needs to work in gdb, adding an
> alias sounds like a reasonable solution.

I would suggest that if the target provides a description then we
should be pretty conservative with which aliases we add.  I don't know
if adding a dscratch to dscratch0 alias would be something I'm in
favour of or not.  Though I'm conflicted, because it seems obvious
that GDB should create aliases for things like ra/x1 sp/x2, etc, so
maybe I'm just x-reg elitist...

>                                           There is a DECLARE_CSR_ALIAS
> in include/opcode/riscv-opc.h for dscratch and other affected csrs,
> but I guess gdb isn't handling those at the moment

No but we probably should.  I took a quick look at this but ran into
some issues.  I'm going to try and see if I can get this all figured
out.

Thanks,
Andrew

[1] There are some requirements like the target must announce the full
set of integer registers, but there's no requirement for an exact
match, and as far as CSRs, pretty much anything goes.

[2] I'm willing to be convinced that I messed up, but I'm describing
what _should_ be happening.