[PATCH] riscv: add gdbserver support

[Maciej W. Rozycki]

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