Using gdbstub for enhanced GDB server functionality?

[daniel5151]

Disclaimer: I am the author of the gdbstub crate, so this is a totally shameless plug.

Right at the tail end of one of Ferrous Systems most recent blog posts, it mentioned that probe-rs's GDB server functionality is somewhat immature.

Might I suggest swapping out probe-rs's home-grown GDB Remote Serial Protocol implementation with the gdbstub crate? It implements substantially more of the GDB RSP than probe-rs's current in-tree implementation, and is already being used by several other projects. A full list of supported GDB protocol features can be found here.

I wasn't sure if gdbstub was on your radar, so I thought I'd file an issue just in case!

Oh, and please let me know if there are any glaring issues with the gdbstub API / functionality that would preclude it from being used in probe-rs. I'm very open to feedback, since my long-term goal is to make gdbstub the "go to" GDB RSP crate in the Rust ecosystem!

[Tiwalun]

Thanks for reaching out!

Using gdbstub for the protocol sounds interesting, and would make our life easier.

From a quick look at the API, it seems that the Target trait is usually implemented for a single architecture. The architecture used in our GDB server is only determined at runtime, is it possible to implement this with gdbstub?

[daniel5151]

Thanks for the quick response!

Given that the most common use-case of gdbstub up until now has been as part of full-system-emulators and/or hypervisors, the fact that Target was tied to a single Arch hasn't been too much of an issue. In fact, by having this tight compile-time coupling, the gdbstub API is able to abstract a way a lot of the underlying protocol's warts and details, which makes it a lot more ergonomic to use. For example, the Target-level read_addr and write_addr handers don't expose the raw register data byte-string, instead having gdbstub quietly marshal/unmarshal the data into much more user-friendly arch-dependent structs, which makes reading/writing registers a breeze.

That said, you're not the first to bring up the need for more dynamic Arch/Target implementations! In fact, I just popped open a tracking issue on daniel5151/gdbstub that summarized a past discussion I had about this exact problem: daniel5151/gdbstub#53

In a nutshell, the current gdbstub API is in-fact flexible enough to support runtime configurable Arch/Target implementations, albeit with some caveats.

Most of these caveats are relatively minor perf-related issues (which should be totally acceptable unless you really care about squeezing every last drop of performance out of the GDB RSP). The most unfortunate caveat is that you'll be losing those ergonomic benefits I mentioned above, and will require that GDB raw register data is de/serialized at the target level. Not ideal, but without a substantial rewrite of the Arch API (which is not out of the question!), that's pretty much unavoidable.

[bet4it]

From a quick look at the API, it seems that the Target trait is usually implemented for a single architecture. The architecture used in our GDB server is only determined at runtime, is it possible to implement this with gdbstub?

I use gdbstub on multi architectures which is determined at runtime in my project udbserver. You could check the code to see how to implement it.