gdb/remote - I/O

[Frank Ch. Eigler]

jtc wrote:

: [...]
: Truth be told, I've never used GDB's output packet.  

I wonder if you're in a minority!


: Most targets, even the cheap eval boards available for low end
: microcontrollers have more than one I/O channel, so I use one for
: GDB and another for system I/O.

>From the point of view of test suites and similar automated control,
the fewer physical connections, the better.  Several remote debugging
protocols include console I/O already; we would like to finally bring
"remote" closer.


: But if I needed to route I/O through GDB, I think I'd want some-
: thing richer than a single serial i/o stream.  Perhaps some sort of
: lightweight filesystem layer with open/read/write/close primitives.
: [...] If we're going to change the protocol, why not make it something
: richer than a single stream?  [...]

Yes, this would be a worthwhile exercise, but is way outside the realm
of reasonably small extensions of the remote protocol.


: [...]
: At present, remote_stop() is implemented, depending on the value of
: the remote_break variable, by either a CNTRL-C or a serial break.
: Both suffer from a lack of acknowledgement from the target.  [...]

The lack of a timely response (S/T packet) is an implicit NAK.


: If it's only a console, please explain why this is valuable in the
: real world (as opposed to a toy/trade-show booth demo).  If it's
: something better, the latency is going to kill you.

It's "real world" useful for
- test suites
- fast targets (eg. simulators)


: Andrew> Flow control is a target problem.  That data gets sent across,
: Andrew> ready or not :-)
: 
: I think discounts the problem too easily.  [...]  In effect, this
: requires the agent to be deeply entertwined with target i/o.

That's true, though some degree of intertwining was always involved in
supporting ordinary output packets.  FWIW, I like Fernando's idea of
signalling blocking reads by target stops, i.e., a "pull" model for
input.  It would reduce the need for flow control.


- FChE