Re: [PATCH] riscv: add gdbserver support

Maciej W. Rozycki
2020-01-20T23:33:20Z

Hi Jim,

Thanks for the heads-up!

On Mon, 20 Jan 2020, Jim Wilson wrote:

> > This patch is a base support for Riscv32 and Riscv64 arch. It implemented
> > how to
> > r/w gprs and fprs, identify the software bkpt insns and the *.dat files for
> > regs_info.
> > I have tested it on kernel 5.1.15, and it works normally.

So what are the test suite results compared to the native port?

> I believe that Maciej has a RISC-V gdbserver port also. It would be
> nice to see some comment from him.

Indeed, however I have stalled my work as my fixes for GDB issues
triggered in the course of this effort have never been reviewed in some 2
months now (I continue pinging, but nobody has bothered to pick them up,
even though I think at least some of them are straightforward if not
obvious), so I focused on some GCC issues instead.

Also a bug needs to be fixed with GDB proper not accepting the XML
architecture names generated by itself (i.e. code shared between GDB
proper and `gdbserver') or XML descriptions generated by `gdbserver' are
rejected.

Offhand I can see the proposal fails to implement XML register
descriptions, which I think every modern port is expected to do (we also
need to disallow non-XML-enabled RISC-V stubs in GDB proper, as we
discussed before; I fail to understand why it wasn't done right away with
the initial implementation, as it's quite straightforward and would have
set the policy for debug stubs right from the beginning).

> > Some requirements may be implemented later:
> > 1. if fpu has 64bits in riscv32
>
> This is common, and will have to be fixed, but not necessarily fixed
> in the first version. We also have riscv32 linux targets with no FP
> registers. I don't know what the *.dat files are for, but I think the
> general registers and the FP registers should be separate files if
> possible. If not, then we need 6 dat files, as we have 2 general reg
> sizes and 3 FP reg sizes, and 2*3=6.

I have a version that supports 64-bit FPU across both RV64 and RV32, as
required by the Linux kernel; a fix is required for the native port as
well, which I have made too.

The .dat files are not needed by our port AFAICT, because it generates
the XML description dynamically, and they are only used for the ports that
do it statically.

I'll look into this proposal more deeply once I have fully recovered from
my last week's trip to linux.conf.au; or maybe I'll just post mine
instead, as it lacks some of the deficiencies discussed here and I expect
it to be fully functional if not the XML acceptance bug on the GDB side.

NB my RV64 HiFive Unleashed test results look like below:

=== gdb Summary ===

# of expected passes 58054
# of unexpected failures 621
# of unexpected successes 4
# of expected failures 49
# of unknown successes 5
# of known failures 72
# of unresolved testcases 110
# of untested testcases 100
# of unsupported tests 232

however I have not analysed them further, due to the reasons stated above.

HTH,

Maciej