Re: Standard GDB Remote Protocol

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:

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

That is a very good point.  There is definitly room for overlap.  Once
the hair between the commands and the transport are separated, things
can move more freely.

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

This is starting to sound like IP:-)  Just as long as it isn't as heavy
:-)

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

Agreed.

	Andrew