Re: gdb/remote - I/O

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> The existing remote protocol doesn't support input vis: GDB ->
> Andrew> target (ignoring the ``target cisco'' hack that just sends raw
> Andrew> characters).  I think the current semantics for output are
> Andrew> also weak and I'd like to change them.  In the below I'll try
> Andrew> to sketch out the basic idea.
> 
> Truth be told, I've never used GDB's output packet.  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.  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.

As Frank noted, the testsuite exploits it.

> Andrew> Where <BREAK> is the CNTRL-C character but could be some other
> Andrew> out-of-band character.
> 
> 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.  What
> are your feelings toward a real stop packet?

I suspect we're stuck with the situtation that a ``stop'' or ``break''
should be out-of-band.  I'm actually suprised that no one has suggested
sending a real BREAK instead of that cntrl-c.

> Andrew> Appart from the ``O'' (output) packet, the target never
> Andrew> initiates anything.
> 
> Not that it matters much, but doesn't the cisco variant send a packet
> to indicate section offsets?

It is part of their custom stop packet (N).
It turns out that some of the more exotic PDA OS's could also benefit
from a section offsets packet.

> Are there any other asynchronous events that we might want to be
> informed about that don't require the target to be stopped?  Mapping
> and unmapping shared libraries?  Thread creation, deletion, or
> switching?

That is the thing.  While it would be nice if the remote target didn't
stop, in reality, it does.  For any of these events to be passed back to
GDB, the target has to stop for at least a short period of time.

> Andrew>         -> c (continue)
> Andrew>         <- o<output> (implied halt)
> Andrew>         -> c (continue)
> Andrew>         <- o<more-output> (implied halt)
> Andrew>         -> c (continue)
> Andrew>         <- T... (stop)
> 
> If we're going to change the protocol, why not make it something
> richer than a single stream?  In fact, the i/o protocol doesn't
> have to be part of the remote protocol per se, but the protocol
> could define a mechanism for tunneling packets through from GDB
> to the target and vice versa.

These are both good ideas:

	o	separate the GDB remote protocol
		from its transport layer

	o	implement a new transport
		that supports multiple channels

however that is separate to changing the way the current remote protocol
works.

> Andrew> It makes the behavour consistent with the rest of the remote
> Andrew> protocol.
> 
> Yes.  But it does it by shoehorning what is an asynchronous event into
> a synchronous framework.  I'm not sure it is desirable.

At some level or another, these events need to be synchronized.  For the
target to send console output back through to GDB it will need to
synchronize its self with with the debug server.

> Andrew> The additional round trip is acceptable since the objective is
> Andrew> to implement a primative but (relativly) reliable console.
> Andrew> The objective is not to implement a high speed data link.
> 
> 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.

See Mark and Frank's comments about debugging and testing.
(I actually suspect it would never be used in a toy/trade-show demo - a
demo printing ``hello world'' would just be laughed at by marketing :-)

> Andrew> Input:

> Andrew> Unlike other implementations this doesn't involve making the
> Andrew> protocol asynchronous.  Consequently, it should keep the
> Andrew> target simpler.
> 
> I think you overestimate the difficulty of making a asynchronous debug
> agent.

Actually, I underestimated!  See Mark's comment about no interrupt and
no timer.  On some targets it just ain't possible.

> Andrew> Flow control is a target problem.  That data gets sent across,
> Andrew> ready or not :-)
> 
> I think discounts the problem too easily.  If the target is stopped,
> it can't juggle or empty buffers to read in the new data, it also
> can't send anything up the output channel to throttle the input.  In
> effect, this requires the agent to be deeply entertwined with target
> i/o.

Yes, this was wrong.  Marks's pointed out that the target should poll.

	Andrew