Re: Standard GDB Remote Protocol

[William Gatliff <gatliff at haulpak dot com>]

Steven Johnson wrote:

> Packet Structure:
>
> Simple structure, obviously originally designed to be able to be driven
> manually from a TTY. (Hence it's ASCII nature.) However, the protocol has
> evolved quite significantly and I doubt it could still be used very
> efficiently from a TTY.

True, but it can still be *monitored* quite effectively with a TTY, and
simple things like a ? query are still possible.  If I'm using a TTY then
I'm desperate anyway, so I'm willing to put up with a little pain.  Go to a
non-ASCII protocol, however, and the TTY option is right out altogether, no
matter how desperate I am!

If efficiency/throughput is a problem, then go to ethernet.  At 10/100Mbps,
even the overhead of ASCII isn't a problem for most targets I can think of.

> I think there should be a general timing basis to the entire protocol to
> tie up some potential communications/implementation problems.

The RSP's lack of timing requirements is an asset, as far as I'm
concerned.  See below.

> If a message is only half received, the receiver has no ability without a
> timeout mechanism of generating a NAK signalling failed receipt. If this
> occurs, and there is no timeout on ACK/NAK reception, the entire comms
> stream could Hang. Transmitter is Hung waiting for an ACK/NAK and the
> Receiver is Hung waiting for the rest of the message.

This is something that a stub can handle itself, as a self-protection
measure, without changing the RSP.

A debugging stub running on production hardware would probably need to do
this anyway, while a lab/development system could tolerate a hang (concerns
with rotating machinery, etc. notwithstanding).  So, I don't see any reason
to create requirements, because they're likely to be so target-specific
that you'll never get good agreement on what they should be, and therefore
there will not be any uniform implementations.

In my opinion, a debugging stub is the responsible party for the safety of
a debugging target, because it alone can decide what to do if it thinks
that gdb has "gone away" unexpectedly (line noise, PC/protocol hang,
etc.).  When this is done, nobody cares if gdb hangs, because it doesn't
necessarily cause problems for the target.

From that perspective, it is clear to me that a debugging stub will have to
do whatever it needs to do to protect itself and the target, regardless of
what the RSP says.

So the mission to beef up the RSP in the way you suggest seems
counterproductive.  In the best case, you'll drive the need for gdb
enhancements that won't benefit most people (i.e. timing requirements that
are so loose that targets cannot depend on them); in the worst case, you'll
create gdb behaviors that are incompatible with certain types of targets
(i.e. timing requirements that are so tight that targets and hosts can't
implement them).

> I would propose that something needs to be defined along the lines of:
>
> Once the $ character for the start of a packet is transmitted, each
> subsequent byte must be received within "n" byte transmission times.
> (This would allow for varying comms line speeds). Or alternately a global
> timeout on the whole message could be define one "$" (start sentinel) is
> sent, the complete message must be received within "X" time. I personally
> favour the inter character time as opposed to complete message time as it
> will work with any size message, however the complete message time
> restrict the maximum size of any one message (to how many bytes can be
> sent at the maximum rate for the period). These tiemouts do not need to
> be very tight, as they are merely for complete failure recovery and a
> little delay there does not hurt much.
>
> One possible timeout that would be easy to work with could be: Timeout
> occurs 1 second after the last received byte.
>
> For ACK/NAK I propose that something needs to be defined along the lines:
> ACK/NAK must be received within X Seconds from transmission of the end of
> the message, otherwise a NAK must be assumed.

Good suggestions, but I would prefer that these be general stub design
guidelines that aren't enforced by gdb.  Let gdb be as flexible as
possible, so that it will work with super-smart stubs that do all the
timing stuff properly, as well as stubs that are minimally written.

Gdb is supposed to be a debugging aid; I would prefer that all the protocol
stuff not get in the way of its fundamental mission.

Also, how do you measure byte times on most debugging hosts, particularly
at 115K (my bit rate of choice) and higher?  Such a specification sounds
easy, but an implementation isn't likely to be portable.

And finally, consider the case where an M command is really writing to
flash, and the debugging target gets busy erasing flash sectors (which can
take longer than a second in some cases)?  If gdb retries, things may get
confusing.

> There is no documentation of the recovery procedure, Does GDB retransmit
> if its message is responded to with a NAK? If not, what does it do? How
> is the target supposed to identify and handle retransmits from GDB.

> What happens if something other than + or - is received when ACK/NAK is
> expected. (For example $).

From my own experience, remote.c is kinda fragile where stuff like this is
concerned.  I had been intending to look into this myself next year, but by
then someone else will have certainly beaten me to it.  I think some
improvements have already been made.

> Character Escaping: The mechanism of Escaping the characters is not
> defined. Further it is only defined as used by write mem binary.

That's because this is the only place where it is needed, AFAIK.  And,
since X is optional (and support for it is detected automatically by gdb),
that means that I don't have to implement it if I don't want to.  Bonus for
super-minimal stubs.

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
To teach is to learn.