Re: Standard GDB Remote Protocol

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

>>>>> "William" == William Gatliff <gatliff@haulpak.com> writes:
William> If efficiency/throughput is a problem, then go to ethernet.
William> At 10/100Mbps, even the overhead of ASCII isn't a problem for
William> most targets I can think of.

Yet the protocol should be as efficent as possible.  For many targets,
ethernet and a TCP/IP stack is a heavyweight requirement.  I looked at
cleanly separating the layers in remote.c so I could use UDP some time
ago.  About the same time, the mini-telnet stuff came in which assumes
a stream transport.  Bleh.  

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

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

Although Steven mentioned several alternatives of computing timeout
values from bit rate, message size, etc.; I believe that those are
secondary to his point that the protocol should identify that time-
outs are necessary to guarantee a reliable.  Once they are identified,
the lengths of those timeouts can be implemented by GDB variables or
manifest constants in stub code, etc.  But without them, I think that
we'll continue to have weaknesses in both.


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

William> That's because this is the only place where it is needed,
William> AFAIK.  

It's the only place where it's used now.  But I wouldn't go so far as
saying that it's the only place where it's needed.  Perhaps even more
useful than binary memory write is binary register write.  Registers
are written quite often while stepping through a program.

Likewise, it would be useful to have a binary memory read and binary
register read.  IMO, using the same escaping mechanisms for all such
commands would be good thing.  To do so, I'd put it at the data link
layer instead of inside each command.

        --jtc

-- 
J.T. Conklin
RedBack Networks