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

[Jim Wilson <jimw@sifive.com>]

On Fri, Feb 22, 2019 at 9:42 AM Tom Tromey <tom@tromey.com> wrote:
> With an older gdb (8.2), with remote debugging enabled:
>
>     (gdb) p $fflags
>     Sending packet: $p42#d6...Ack
>     Packet received: 0000000000000000
>     $1 = 0
>...
> However with a newer gdb, with an older qemu, I get a failure:
>
>     Sending packet: $p41#d5...Ack
>     Packet received: E14
>     Could not fetch register "fflags"; remote failure reply 'E14'
>
> Here you can see gdb is sending 0x41.

The renumbering is unfortunate, but there are a lot of historical
problems here, and compatibility with old tools may not be worth the
trouble.  We need to make this work right first, before we can worry
about backward compatibility.

fflags is a CSR not an F register.  But gdb is treating it as both an
F register and a CSR which may lead to some confusion.

Also, fflags is not a real register.  It is an alias for a field
inside the fcsr register.  If gdb is talking to something like
openocd/qemu that can translate fflags to fcsr that is OK, but for a
native riscv-linux gdb trying to read fflags won't do anything useful,
gdb needs to translate fflags into the fcsr field itself or this isn't
going to work.  Though maybe we can do something inside one of the
riscv-linux files to handle this.

There are a lot of problems with the old qemu gdbstub support.  I have
a patch set submitted for qemu to add the gdb xml files and proper
gdbstub support to use them.  gdb+qemu works much better with these
patches.  This patch set has been approved, and is queued for commit
behind one other patch in progress I think.  With this patch,
accessing fflags works with both a system qemu and a user qemu using
the current development gdb (8.3 pre-release).

(gdb) info registers fflags
fflags         Sending packet: $p4c#07...Ack
Packet received: 0000000000000000
Packet p (fetch-register) is supported
0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
(gdb)

Jim