Re: Standard GDB Remote Protocol

[Steven Johnson <sbjohnson at ozemail dot com dot au>]

William Gatliff wrote:
> 
> Steven Johnson wrote:
> 
> > Packet Structure:
> >
> > Simple structure, obviously originally designed to be able to be driven
> > manually from a TTY. 
> 
> True, but it can still be *monitored* quite effectively with a TTY, and
> simple things like a ? query are still possible.  

Im not criticizing or suggesting a change, im making an observation.
Whether $ or STX or some other packet structure is used is of little
import. Advantageously, the GDB packet structure is complete and
independent from the message it contains. Which is a good thing. This is
very different from many "proprietary" binary protocols i've used where
the packet and message are confused and mingled, so that there is no
good separation of packet handling and messaging. I actually found this
a nice surprise, from all of the protocols i've dealt with few people
seem to realize the importance of this in good comms design.

> 
> If efficiency/throughput is a problem, then go to ethernet.
> 

I wasn't suggesting it was in-efficient to use from a program. I was
making the general statement that it would be difficult to debug a
target just using a TTY and a target with the stub. Efficiency meant,
time in working out the message to key in and deciphering the response.
You have no arguments from me that being able to easily observe the
message stream for the purposes of debugging an implementation is a good
thing.

> 
> 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.
>

Yes, here's the issue. The document is completely lacking in stub
implementation guidelines. IMHO, there needs to be a section of the
protocol (or comments throughout it) that give this sort of information
and advice to implementers of stubs. An implementer can then take it or
leave it, but at least the document needs to advise how a well behaved
stub could/should operate. There needs to be more than just "Here is a
Packet", there also needs to be documentation along the lines of "Here
is a Packet, a receiver should do this when it gets it. Possible
problems in reception are, some solutions to these problems are." It
would add meat to the bones that are currently described and aid in the
implementation/debugging of a stub. 
 
>
> 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.
> 

I'm not suggesting it does.

> Also, how do you measure byte times on most debugging hosts, particularly
> at 115K (my bit rate of choice) and higher? 
>....<snip>
> 

No arguments here either, I was speculating about possible solutions. I
wasn't saying this must be done. I would agree there are many ways to
skin that cat, and some are easier than others, depending on your host.
I also recognize that stubs probably don't do this now and the world
hasn't come to an end. 

> > 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.
> 

I see this as a far more important issue than the timeout stuff,
although they are related. Remote.c is probably fragile, because there
is no documentation on how it should work. It wouldn't surprise me if
there was inconsistency of the implementation in GDB because of this.

> > 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.
> 

Again I agree with this. I was making the observation that Character
Escaping is likely to become more prevalent as the protocol evolves. To
define character escaping around one message could create a situation
where different messages that require it implement different mechanisms.
There is evidence of that occurring in other messages, like the ':'
shouldn't be used, but some messages do statement. 

What would probably be more appropriate is to state how escaping is
performed where required as part of the base level protocol. Then in the
message put a statement like, "This message contains binary data and
must be Escaped using the standard escaping mechanism defined above".

This way if you don't implement any of those messages, you don't need to
implement Escaping. But it advantageous in that it defines how escaping
will be used in any/all messages that require it. I think the same
should be said for RLE. Maybe each message needs a check list that
states what features it may use like this:

My new Message          U                    My comments on this message
                                             Uses RLE: NO
                                             Uses ESC: YES

At least this would clearly state where both of these mechanisms can be
used, and where they can't.


Further, Im not stating any implementation should change. What Im trying
to do is come to terms with the documented protocol. Identify weaknesses
in that documentation and propose ways the document can be strengthened
to more accurately reflect what is desired of an implementation.

Steven Johnson
Managing Director
Neurizon Pty Ltd