Does anyone have remote gdb protocol info

[gregory.menke at gsfc.nasa.gov]

Steven Grunza writes:
 > I'm running into numerous problems with the tools we recently 
 > purchased.  The latest is the software portion of the tool can't find the 
 > sources.....  I would really like to just use gdb but the hardware portion 
 > of the debugger doesn't understand the gdb remote protocol.
 > 
 > The hardware portion of the debugger has it's own protocol but it connects 
 > to the software portion by Ethernet.  With a little experimentation I 
 > should be able to figure out the hardware's protocol.
 > 
 > Then all I would need is to write a small protocol translator to convert 
 > gdb's remote protocol into the hardware's protocol (both directions, of 
 > course).
 > 
 > Does anyone know where the protocol used by gdb when using
 > 
 >                  target remote hostname:portnum
 > 
 > is documented?  The "Debugging with GDB" document gives some clues but I'm 
 > working on a slightly different approach.  Section 16 mentions the 
 > gdbserver program that runs on the target system and connects to the 
 > host.  In theory I should be able to reverse engineer gdbserver but my 
 > guess is that the protocol it uses to talk to the host is documented 
 > somewhere.  The sparc-stub.c file is mentioned as a starting point but an 
 > actual document on the protocol would be better.

Calling it a protocol is something of a stretch, its more of an
organic evolution with snapshots taken at various points by gdb
releases.  The documentation for it is very poor.  Essentially, its a
command/response deal with some more or less vaguely defined packet
formatting rules.  In rtems, the MIPS and i386 (others too I think)
have gdb stubs in the bsp's, meaning they can be hooked up to exeption
vectors, allowing the user to trace execution on the target, while
enjoying a full debugger interface on their host.

The gdb docs are the only place I've seen the packet formats
documented.  The protocol and debugging capabilities have evolved as
gdb has gotten fancier.  gdb sort of tries to acclimatize itself to
the capabilities of the gdbstub, so keeping the stubs modern helps
maximize functionality.

Fundamentally, gdb sends commands to the debugee(?), asking for things
like cpu registers, memory dumps, thread info, store breakpoint, clear
breakpoint, go, etc... and the debugee responds with the appropriate
data or something usefully incorrect.  The transport over which this
occurs is up to you.  We use the 2nd built-in serial port on our
Mongoose MIPS bsp, its apparently possible to use tcp/ip as well.  The
transport only has to support a bidirectional character stream,
something close to 19200 baud is quite fast enough.  The nice thing
about a stub is its very small and simple, and well suited for linking
into a running target.  Naturally, your gdb must be cross-compiled to
run on your host but understand the target.

There are about 5 to 7 (IIRC) commands a debugee must support and
others it can fake as it chooses.  The MIPS gdb stub does a resonable
job of it I think- and I've used it to trace C and C++ code on our
target board.  When working with it, my reference was the i386 stub,
the gdb 5 source and the gdb info page.

If you're going to write a protocol converter, you can probably avoid
the cross-compiling gdb dance and just act like gdb itself.  The stubs
are supposed to be more or less stateless (breakpoints aside), so your
translator could probably use them unconventionally fairly easily- in
the sense that your pattern of commands would be different from gdb's.
Since debugging is pretty much the same everywhere, I think you may
find your debugger's commands relate pretty easily to gdb's- and thus
to the stubs as well.  It is possible such a protocol converter could
reasonably work for many different targets.

I've never used gdbserver, but I can't imagine its going to use a
fundamentally different protocol.

Gregm