Using `gdbstub` for the GDB Remote Serial Protocol

[daniel5151]

Hey there!

This is a totally shameless plug on my part, but I was wondering if you were aware of the gdbstub crate? gdbstub provides a generic, typesafe, and ergonomic Rust API for implementing GDB remote targets. It already implements quite a substantial chunk of the GDB RSP (including reverse execution!), and is being used by quite a few projects, both big and small.

I wanted to open this issue for a couple reasons:

• To solicit your thoughts on gdbstub (after all, not that many folks implement the GDB RSP from scratch. There are dozens of us!)
• Ask whether you'd be open in pooling our efforts
• Ask if there are any glaring feature omissions from the current gdbstub implementation that would make integrating it into rd an absolute non-starter*

*I can already tell that gdbstub is missing a couple protocol extensions (e.g: reading the target's auxv, some filesystem packets, fetching data from thread local storage), though these are all quite straightforward to implement.

[khuey]

Maybe I'm missing something obvious but I don't see any reverse anything documented at https://docs.rs/gdbstub/0.4.5/gdbstub/

[daniel5151]

Reverse execution support landed on the dev/0.5 branch a while back (see https://github.com/daniel5151/gdbstub/pull/48).

I'll be publishing a 0.5 release in the next week or two, at which point docs.rs will catch-up to the work that's actually done in-tree.

In the meantime, check out the CHANGELOG for a overview of what's coming down the pipeline.

[sidkshatriya]

Thanks for reaching out @daniel5151 regarding gdbstub! Part of rd's objectives are to use well maintained crates rather than re-invent the wheel. As an example, while rr does a lot elf stuff itself, rd uses the goblin crate.

Unfortunately, I didn't know about the gdb_stub crate when I ported the gdb connection related functionality from rr to rd. If I had known I might have explored the possibility of using it.

The current gdb connection functionality seems to be working fine in rd. I have a good number of things remaining before I can say that the rd port has achieved full parity with rr. My priority is to tend to those. Maybe in the future I will cycle around to gdb_stub to see whether I can use it and whether it might even be advantageous to use than the current custom rr derived implementation.

I appreciate you reaching out to me. I'll keep an eye out for your project in the meanwhile and maybe even try to dive into it one day. Please feel free to play around with rd also. If you run replay like so:

$ RD_LOG=all rd replay

you will be able to see detailed info on the serial protocol packets as they fly back and forth between gdb front-end and rd. I'm mentioning this in case you want to see this in action in rd. (The relevant gdb connection code is in gdb_connection.rs)

[daniel5151]

Thanks for the quick response, and for taking the time to answer my questions! It's certainly somewhat of a relief to know that gdbstub's spotty adoption is most likely an advertising issue rather than an implementation issue 😅

In any case, if you ever decide to revisit the GDB integration in rd, do consider giving gdbstub a shot! It's designed to be a "drop in" way to add GDB debugging to any project, and hooks into whatever existing code your project provides for performing basic operations such as reading/writing registers/memory, setting/removing breakpoints, etc... (i.e: you simply provide an implementation of the Target trait, and gdbstub will take care of the rest). Based on feedback from folks who've successfully integrated gdbstub into their own projects, they were able to get a basic GDB debugging session up and running within just a couple hours.

Feel free to reach out if you've got questions about gdbstub, and don't hesitate to file an issue on the repo if there's a feature you'd like to see implemented! As I'm sure you're aware, the GDB RSP is massive, and while the long-term goal is to support all of it, the short-term goals are guided by the needs of existing gdbstub users.

Best of luck with rd, and I'm excited to see how the project will continue to evolve!

[sidkshatriya]

Cool!

---

BTW if you every end up exploring rd and its gdb serial protocol code, a less noisy way to just see the gdb packets would be;

$ RD_LOG=all:warn,gdb_connection:debug rd replay

Instead of:

$ RD_LOG=all rd replay

which will be just too noisy.