Re: Standard GDB Remote Protocol

[Andrew Cagney <ac131313 at cygnus dot com>]

Steven Johnson wrote:

> It is based on my First Read of the current online version of protocol
> specification at:
> http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html

> 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. That said, it still demarks frames effectively.

One really useful thing to know is the command:

	(gdb)  set remotedebug 1

(If there isn't already) there should be a reference to that command (or
is successor).

> Sequence Numbers:
> 
> Definition of Sequence ID's needs work. Are they necessary? Are they
> deprecated? What purpose do they currently serve within GDB? One would
> imagine that they are used to allow GDB to handle retransmits from a
> remote system. Reading between the lines, this is done to allow error
> recovery when a transmission from target to host fails. Possible
> sequence being:

I guess the best description is ``in limbo''. Sequence ID's have been in
the protocl for as long as anyone can remember but, at the same time no
one can actually remeber them being used.  True?

I didn't deprecate it as there does need to be something for handling
things like duplicate packets (so that finally the protocol can be used
reliably across UDP and the like).  Someone needs to sit down and fully
specify this (or better) identify an existing protocol that can be used
to specify the sequence-id's behavour.

There should at least be a note pointing out the current status of
sequence-ID's.

> The 2 primary timing constraints I see that are missing are:
> 
> Inter character times during a message transmission, and Ack/Nak
> response times.
> 
> 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.
> 
> 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.

How GDB behaves should be clarified.  However, any definition should
avoid refering to absolute times and instead refer the user back to a
number of knobs that can be tweeked from the GDB command line.

This in turn suggests that there should be a section describing the
protocol's behavour with direct references to things like the
configurable timers.

I've sometimes wondered about doing a proper SDL spec.... :-)


>  Identified Protocol Hole:
> 
> Lets look at the following abstract scenario (Text in brackets are
> supporting comments):
> 
> <- $packet-data#checksum (Run Target Command)
> -> +                                     (Response is lost due to a line
> error)
> (Target runs for a very short period of time and then breaks).
> -> $sequence-id:packet-data#checksum (Break Response - GDB takes as a
> NAK, expecting a +, got a $).
> <- $packet-data#checksum (GDB retransmits it's Run Target Command,
> target restarts)
> -> +                                     (Response received OK by GDB).
> (Target again starts running.)

That is correct.

The protocol, as it currently stands, is only robust against overrun
errors (detected by a checksum failure).
In pratice this has proven to be sufficient for almost all situtations.
Because of the request/response nature of the protocol the probably of a
dropped/corrupt ACK packet is very low.  (I'm not saying this a good
thing, just a lucky thing :-)

This would suggest that at least the spec should make the known
limitations clear.
This is another reason why I've not simply abandoned the sequence-ID -
I'm hopeing someone will do something about this :-)

>  Run Length Encoding:
> 
> Is run length encoding supported in all packets, or just some packets?
> (For example, not binary packets)
> Why not allow lengths greater than 126? Or does this mean lengths
> greater than 97 (as in 126-29)
> If binary packets with 8 bit data can be sent, why not allow RLE to use
> length also greater than 97. If the length maximum is really 126, then
> this yields the character 0x9B which is 8 bits, wouldn't the maximum
> length in this case be 226. Or is this a misprint?

FYI, Any packet can be RLE.  RLE handling is done as part of unpacking a
packet.  The code doesn't know if it is binary/ascii at that point.

The old RLE size reflects the fact that a 7 bit printable character was
used (the actual equation is RLE - ' ' +3).  While binary packets could
extend this, I don't think that there is any benefit.

I've rarely seen an RLE stub in pratice.  The benefits would be
significant.

GDB doesn't send RLE packets and, I think, it should.

> Why are there 2 methods of RLE? Is it important for a Remote Target to
> understand and process both, or is the "cisco encoding" a proprietary
> extension of the GDB Remote protocol, and not part of the standard
> implementation. The documentation of "cisco encoding" is confusing and
> seems to conflict with standard RLE encoding. They appear to be mutually
> exclusive. If they are both part of the protocol, how are they
> distinguished when used?

It's an unsupported extension.  Idea's from CISCO are slowly being
rolled back into the normal protocol.

> Deprecated Messages:
> 
> Should an implementation of the protocol implement the deprecated
> messages or not? What is the significance of the deprecated messages to
> the current implementation?

(Your not the first one to ask that one :-)
They are there as a very strong deterant for people thinking of re-using
the relevant letters.  This should probably be clarified.

> Character Escaping:
> 
> The mechanism of Escaping the characters is not defined. Further it is
> only defined as used by write mem binary. Wouldn't it be useful for
> future expansion of the protocol to define Character Escaping as a
> global feature of the protocol, so that if any control characters were
> required to be sent, they could be escaped in a consistent manner across
> all messages. Also, wouldn't the full list of escape characters be
> $,#,+,-,*,0x7d. Otherwise, + & - might be processed inadvertently as ACK
> or NAK. If this can't happen, then why must they be avoided in RLE? If
> they are escaped across all messages, then that means they could be used
> in RLE and not treated specially.

Beyond the X packet there is no escape mechanism.  GDB assumes the
connection is capable of transfering printable ascii.  Escaping
characters should probably be left to a lower layer.

(A side note: The existing protocol spec mixes the packet specification
and transfer in with the specification of the actual packet body - not a
good way of defining a spec.)

> 8/7 Bit protocol.
> 
> With the documentation of RAW Binary transfers, the protocol moves from
> being a strictly 7 bit affair into being a 8 bit capable protocol. If
> this is so, then shouldn't all the restrictions that are placed from the
> 7 bit protocol days be lifted to take advantage of the capabilities of
> an 8 bit message stream. (RLE limitations, for example). Would anyone
> seriously be using a computer that had a 7 bit limitation anymore
> anyway? (At least a computer that would run GDB with remote debugging).

I suspect that it will still be there for a while longer.  Even if there
were no broken serial controllers there will still be broken stubs :-(

> Thoughts on consistency and future growth:
> 
> Apply RLE as a feature of All messages. (Including binary messages, as
> these can probably benefit significantly from it).
> 
> Apply the Binary Escaping mechanism as a feature of the packet that is
> performed on all messages prior to transmission and immediately after
> reception. Define an exhaustive set of "Characters to be escaped".
> 
> Introduce message timing constraints.
> 
> Properly define sequence-id and allow it to be used from GDB to make
> communications secure and reliable.

FYI, the one I really wish someone would persue is a mechanism that
allowed GDB to send console input down to the target. Cisco added code
that does something however it isn't robust.

To do this, I suspect that some of the other issues you've raised would
also need to be addressed.

	thanks,
		Andrew