This is the mail archive of the
mailing list for the GDB project.
Re: gdb/remote - I/O
- To: Stephane Carrez <Stephane dot Carrez at Sun dot COM>
- Subject: Re: gdb/remote - I/O
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 26 Mar 2001 10:39:45 -0500
- Cc: gdb at sources dot redhat dot com
- References: <200103260902.LAA00204@sunchorus.France.Sun.COM>
> 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
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,