Gdb Remote Stub Documentation?

[slinga-homebrew]

I'm interested in adding a remote gdb stub to a video game emulator so I can debug with Ghidra. I found this thread: #2652.

Can someone point me to documentation for creating a gdb remote stub? The gdb docs are terrible.

[d-millar]

Maybe:

https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html

or

https://medium.com/swlh/implement-gdb-remote-debug-protocol-stub-from-scratch-1-a6ab2015bfc5

You're definitely right about the gdb docs, although ultimately the RSP pages are useful. We do have some old code implementing the RSP protocol, but it's pretty crufty and in Java. There are better examples out there these days.

[slinga-homebrew]

Thanks for the quick response, I'll review the links. A few more questions:

1. GADP is a protocol Ghidra made right? Instead of implementing a gdb stub is there a GADP stub I can implement instead?
2. I was also thinking about just having the emulator create a trace file and viewing that in Ghidra. Is there documentation on the trace format?

[d-millar]

You could implement a GADP stub, but that would probably have limited utility. A proper gdbstub would certainly give you more flexibility in the future, given both gdb and lldb could use it as well as any front end like Ghidra or IDApro. As noted, GADP is a strictly Ghidra thing. Keep in mind too, you really don’t need to implement all of RSP. Mostly, you’d need stop/start, read/write registers/memory, and qSupported.

With regard to trace files, we currently don’t support any raw trace formats. We support windbg/kd traces, but that is through the dbgmodel API, not the raw file format. Ultimately, the plan odd to do the same for rr.

[slinga-homebrew]

Just to clarify, in the debugger, "Open Trace" is only for WinDbg style traces? I think Ghidra should definitely have it's own trace format IMHO. I believe WinDbg only supports a few architectures.

[d-millar]

Ah, OK, sorry - that's a different thing.... (We need more names for tthings.) So the debugger does have an internal trace mechanism, which we variously refer to as the recording or the trace. It record all the events for a debugger session. This is not a "proper" trace in the following sense. If you were to, say, single-step your target three times and then run until a breakpoint, you would record the register state for each of the three steps and the place time when the breakpoint hit. It would not record intermediate values held during the interval between the last step and the breakpoint hit event. Also, only visible memory would be recorded.

Those traces are kept in "program" format, i.e. they can be saved and loaded the same way Ghidra program files can.

FYI, there's also a script (somewhere) in the debugger for loading portions of a windbg/kd-style trace. Might be of use if you're thinking of doing the same for some other trace format. The issue with trace files for us is their relative complexity and lack of standardization. Seems to be very use-case dependent, i.e. do you need full information, how much space are you willing to alot for storage, how much time are you willing to wait for trace-traversal, etc.

[d-millar]

P.S. If you have recommendations, send them our way. We're always open to suggestions!

[astrelsky]

P.S. If you have recommendations, send them our way. We're always open to suggestions!

A pseudo example of a GADP implementation would be nice.

[pjsoberoi]

There are a number of reasons to avoid reliance on gdb stubs:

1. gdb is presumably designed to support code generated by gcc. The design goals of Ghidra are different.
2. There are many processors not supported by gcc
3. gdb rsp is a 7-bit text protocol designed for serial links. In 2022 there is no reason for this. We should have a fast binary protocol.
4. gdb is a local first debugger. What I mean by that is not of all the local debugging features are accessible via the remote interface. To be fair I am referring to gdbmi.
5. There are billion revisions.
6. Poor documentation.
7. A proper remote interface would allow for the creation of various frontends. Do you remember DDD? ::shudder::

I'm not saying to drop support for gdb, but please create a standard for GADP that other open source projects can implement.

[d-millar]

Hmmm, OK - couple of points to further the discussion, although I should caveat this with Dan (@nsadeveloper789) designed the protocol and is really the expert here.

So PJ's points are well-made and demonstrably true. RSP is a fairly archaic protocol with some, shall I say, "interesting" design decisions. KD (the windows debugger protocol) has similar issues, albeit is somewhat more standardized. Re point 3, GADP is "fast enough," but I think I can safely say it was not designed for speed. GADP is built on top of Google protobuf, so building a server in C++, Java, or Python should be relatively straightforward. The methods you would need to support are spelled out in Gadp.java. There are 25 of them, and you'd only need to implement the ones you believed your target needed to support.

The tricky bit, however, is you need a "model", i.e. an implementation of the AbstractDebuggerObjectModel, paired to the server implementation. I think this could be any of the existing model or a new one, but you'd probably want to put some thought into your choice. The primary implementations are those for the dbgeng, gdb, lldb, and jdi interfaces. Given they get translated into the protocol, the choice is somewhat arbitrary, but the model reflects the arrangement of objects on your target, i.e. are there sessions, processes, threads, modules, etc. The object hierarchies are all expressed as abstract sets of either attributes (named key/value pairs) or elements (sets of objects of the same type) and handled through the Gadp RESYNC method.

The other methods correspond to interfaces on the objects that reflect "special" properties of the object. For example, objects, such as processes or threads, should support the interface TargetResumable and the method Gadp RESUME because they can be resumed. Assuming you are writing a server, this means parsing Gadp.RESUME_REQUEST and generating a GADP.RESUME_REPLY. Most of the methods are assumed to be asynchronous, i.e. we operate on a push model. Off the top of my head, I don't remember which part of the protocol passes the interface associations. Will try to find that and/or get Dan to weigh in.

D