gdb/remote - I/O

[Andrew Cagney]

> This is what the ChorusOS DebugAgent is doing.  This has some advantages
> (when you debug you can stop easily at the output/input), but the big draw
> back is that this is very slow.  A second drawback is that this is highly
> intrusive for the target program (here, this will depends on the implementation
> of the gdbserver/serial line driver on the target).

Good grief!  Perhaphs the idea isn't as tacky as I first thought :-) 
Yes, it has all of those problems.

> What is interesting is that we often think in implementing the non-intrusive
> output (ie, no implied halt).  So, I suggest this kind of behavior become
> an option.

It gets complicated.  Consider GDB's existing ``O'' packet as an example
of what to not do.  Unless the target is doing a synchronous call into
the monitor to perform the transfer (and hence intruding), the
implementation is most likely broken. GDB could send a <break> slam bang
in the middle of that ``O'' packet transfer and hence, have that request
lost.

Perhaps the lack of performance should be documented as a ``feature''
:-)  It would encourage people with console performance problems to
re-implement their console using a separate transport.

Thanks for this feedback,

	Andrew