This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb/remote - I/O
- To: jtc at redback dot com
- Subject: Re: gdb/remote - I/O
- From: fche at redhat dot com (Frank Ch. Eigler)
- Date: 28 Mar 2001 11:54:15 -0500
- Cc: Andrew Cagney <cagney at cygnus dot com>, GDB Discussion <gdb at sources dot redhat dot com>
- References: <3ABBDDE4.7C22709D@cygnus.com> <5mhf0fov3q.fsf@jtc.redback.com>
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