Re: Standard GDB Remote Protocol

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
jtc>
jtc> These are all great, but I'm not sure how much can been within the
jtc> confines of the existing protocol.

Andrew> As a vague suggestion of a ``five year'' gdb-protocol plan:
Andrew>
Andrew> 	v2.0: Formalize the lower layers (transport, ...?)
Andrew> 		(Where's my AST networks book :-) and address
Andrew> 		issues such as reliability.
Andrew>
Andrew> 		The command set would remain the same - warts
Andrew> 		and all.
Andrew>
Andrew> 	v3.0: Look at the actual gdb command set

Mine has been at my side for the last week or so, in the vain hope
that I'd have a few minutes to spare to participate in this thread.
I've been chastised a few times in the last week about having the
'obsolete' second edition.  :-)

I think that formalizing the existing packet transport is essential.
To move forward, we must first know where we stand.  Even if we are
not able fix all of the problems (because doing so would require
incompatible changes to the framing mechanism, etc.), we should be
able to come up with a list of best or recommended practices and
ensure that remote.c and the sample stubs adhere to them.

Andrew> If the two can be separated then, there is some hope of being
Andrew> able to move forward.

If the two layers can can be separated, I see no technical reason that
changes to the command layer be delayed until changes to the transport
layer are completed.  In an ideal world, work on both could progress
in parallel.  However, I suspect that the people interested in
improving the transport layer are the very same people interested in
improving the command layer.  Thus sequencing the projects is probably
the right thing to do.

Andrew> The alternative, as always, is to start again from scratch.

I've been convinced that a new protocol is needed for the last year or
so.  At the same time, I am glad I didn't start designing/implementing
one at that time.  I believe the likely result of such an effort would
have been unsuccessful.  

During the last year, besides complaining about the existing RDP :-),
I've been able to put a lot more thought into the limitations of the
RDP and how I'd address them.  I feel I'm in a much better position 
to do it right now than I was then.

Andrew> (As for the mini-telnet, if someone would like to propose a
Andrew> decent telnet extenstion to the protocol then, I'm all ears)

If we change the lower levels, this becomes easy.  Each packet would
have a 'protocol' field which would indicate which upper level stack
would handle the packet.  One value would indicate be a GDB command/
response protocl.  Another would be a Link Control Protocol used to
establish/negotiate link layer options (8 vs. 7 bit, hex vs. base64
encoding, RLE compression, etc.).  

To replace minitelnet, a lightweight 'protocol' to transfer console
i/o to and from the target.  With a bit more effort, a virtual i/o
scheme could be invented so the target could use the host's file-
system and devices.

        --jtc

-- 
J.T. Conklin
RedBack Networks