Add (partial) support for RISC-V

[thomashk0]

Hey,

This PR contains two commits:

• A first that implements the Arch trait for RISC-V 32/64 bit
• A second one that add support for the "Read register command" of the RSP protocol ('p' command), this is actually needed for debuging RISC-V programs. GDB is querying some specific CSR registers through this command (mstatus, mpriv, ...).

Currently I have a RISC-V softfp toolchain for testing. I will try to add support for floating-point RISC-V 32 and 64 as well soon.
Let me know if the commits need some rework.

Thanks for your awesome gdbstub crate, it works like a charm on my emulator !
Thomas.

[daniel5151]

Hey Thomas, thanks for the PR!
Always glad to see another project successfully integrating gdbstub!

I'm don't think I'll get the chance to give the code a proper review today, but from a quick glance, the Arch implementation looks pretty good!

That said, could you please split the read_register functionality into it's own PR? The proposed API is leaking part of the underlying GDB protocol (namely, the reg_number: usize parameter), which is something gdbstub has tried to avoid. I've already got some ideas on how to tweak it, which I'll leave in a comment on the new PR once it's open.

[thomashk0]

Thanks!

I forced-pushed the Arch trait-only in this PR.
The new PR for discussing the read register API is here: #22 .

[daniel5151]

Just a couple of doc-related nits, but other than that, this LGTM 👍

[thomashk0]

Thanks for the reviews! I hope I fixed them :)

Let me know if you want me to rebase into a single commit before merging.

[daniel5151]

Nice! Lets ship it 🚢

[daniel5151]

Alright, it's merged in 🎉

A couple of post-merge comments:

• If you end up adding support for the floating-point RISC-V extensions, take a quick look at this discussion Add x86_64 support #11 (review) on the "Add x86_64 support" PR, and this Support fine-grained control over Target Features #12 issue. Namely, the current Arch trait doesn't have any easy way to mix-and-match target features (e.g: for RISC-V) without a combinatoric increase in concrete impls.
  • For now, it'd probably be fine to just add a new struct RiscvFpuRegs + RiscvWithFpu arch implementation.
  • I'm no RISC-V expert, but a cursory glance at the arch shows that the other ISA extensions don't actually add any new registers, so having this small amount of redundancy shouldn't be too much of an issue.
• Unless there's some urgent need, I'd like to hold off on publishing a new version of gdbstub to crates.io until the floating point extension implementation is in (or I decide to release a new breaking version will all the misc. changes from the master branch). Is that alright?

[thomashk0]

Thanks Daniel for the merge and the suggestions !

I planned to start with two different structs as you suggest. AFAIK, RISC-V extensions do not add general registers (they may introduce control register though (CSR), but I think GDB would query them through a single read register 'p' command). I think with and without FP cover 90% of RISC-V use cases !

I have no urgency to have it upstream on crates.io, I can stay on my fork as long as needed !