Re: [PATCH] gdb/riscv: Add target description support

[Joel Brobecker <brobecker at adacore dot com>]

Hello,

> On Sat, Feb 23, 2019 at 12:51 PM Andrew Burgess
> <andrew.burgess@embecosm.com> wrote:
> > I think we should be OK.  The existing CSR feature file should
> > possibly be deleted, it's not actually used right now.
> 
> I added the gdb CSR feature file to qemu in my patch.  The lack of
> register numbers means I had to add a table to translate the xml CSR
> register numbers into actual hardware numbers inside qemu.  But this
> does work.  For the subset of CSRs that both qemu and gdb know about,
> I can print register values from gdb and it works.  This is an
> important feature for people using system qemu to debug bootloaders,
> and maybe kernels.  This is part of the reason I wrote the qemu
> gdbstub support.  For user qemu, we don't allow CSR access of course,
> other than the ones readable from user space like fcsr.
> 
> (gdb) target remote :1234
> Remote debugging using :1234
> 0x0000000000001000 in ?? ()
> (gdb) set debug remote 1
> (gdb) info registers misa
> misa           Sending packet: $pa0#01...Ack
> Packet received: 2d11140000000080
> Packet p (fetch-register) is supported
> 0x800000000014112d RV64ACDFIMSU
> (gdb)
> 
> I'm not sure what adding registers numbers to the gp and fp xml files
> will do to the qemu support.  I will have to test that.  Hopefully
> there is no effect unless I add the new files to qemu, in which case I
> might need to update the gdbstub support then to match the new
> numbers.  My understanding is that the qemu copy of the files is
> supposed to be the same as the gdb copy of these files, but I'm not an
> expert on this.  This is true for several targets that I checked.
> 
> OpenOCD also has support for sending a csr xml file to gdb, though of
> course it does not use the gdb version of the file.  It has (or
> creates) ifs own csr xml file.

I think if QEMU sends an XML with the various register description,
then whatever numbering GDB uses by default will no longer apply,
and so things should just-work(tm) regardless of what GDB decided
to do in terms of register numbering.

I think the work you're doing in QEMU can only be a good thing which
will robustify the debugging, because they will avoid the need to
synchronize QEMU and GDB versions.

I'd like to suggest we do try to restore the original register
numbering in GDB as well, though. I've discovered recently that
it's not always so easy to switch to a newer version of QEMU.
So I think Andrew's patch, if good, should go in as well (and be
backported to GDB 8.3 as well).

-- 
Joel