Re: RISC-V: Is it reasonable to extend current target_description for KGDB?

[Jim Wilson <jimw@sifive.com>]

On Tue, Oct 15, 2019 at 12:43 AM Vincent Chen <vincent.chen@sifive.com> wrote:
> namely 32 GPRs, $PC, $sstatus, $sbadaddr and $scause.  Therefore, from
> the viewpoint of KGDB, if the register list of the 'p' packet can
> include these 36 registers, the complex implementation for the
> register query flow will be unnecessary.

We don't have a dedicated RISC-V gdb developer.  If you need gdb
patches, you may need to write them yourself.

Excluding riscv linux native, the other important targets (openocd and
qemu) use xml, and would not be affected by changes to the default
register list.  I don't know how this would affect riscv linux native.
Someone would have to try it and see.  But since we use ptrace instead
of remote, I don't think that it would be affected.  We probably have
other unknown targets that might be affected but no way to identify
them.  There are a lot of people using RISC-V, but not very many
contributing back to the FSF sources, or even the RISC-V Foundation
sources.  I think Maciej may be working on the missing RISC-V
gdbserver port, so his work might be affected, but I would expect
gdbserver to use xml also and hence it should be OK.

One possible solution is to add a RISC-V specific command to choose
the register set used for the default p packet.  That way, if there
are problems with adding registers to it, people have the option to
switch back to the old way.  We already have the "set riscv
use-compressed-breakpoints [auto|on|off]" command.  So we could add a
similar command to choose the number of registers in the default p
packet, try changing the default to the full 36 register set, and wait
to see who complains.  People that complain can be told about the
command to switch back to the old 32 (33?) register set.

Jim