Re: gdb/remote - I/O

[jtc at redback dot com (J.T. Conklin)]

>>>>> "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.

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?

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?

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?

Andrew> I'd like to change the protocol so that the output mechanism is
Andrew> synchronous.  That is, instead of:
Andrew>
Andrew>         -> c (continue)
Andrew> 	<- O....  (hex output)
Andrew> 	<- O....  (more hex output)
Andrew> 	<- T... (stop)
Andrew>
Andrew> The output mechanism is treated like any other continue response.  That
Andrew> is, it halts the target and waits for further input vis:
Andrew>
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.

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.

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.

Andrew> It is possible to implement this in the existing GDB without
Andrew> significant change.

Agreed.


Andrew> Input:

Andrew> For input, GDB would first get the targets attention (<BREAK>)
Andrew> then pass down the input and finally resume the target vis:
Andrew>
Andrew>         -> c (continue)
Andrew> 	<BREAK>
Andrew> 	<- T<sigint> (stop)
Andrew>         -> i<input>
Andrew> 	<- OK
Andrew>         -> c (continue)
Andrew> 	.....
Andrew> 	<- T.... (stop)
Andrew>
Andrew> A refinement might see:
Andrew>
Andrew>         -> c (continue)
Andrew> 	<BREAK>
Andrew> 	<- T<sigint> (stop)
Andrew>         -> c<input> (continue with input)
Andrew> 	....
Andrew> 	<- T.... (stop)

Andrew> The interaction is consistent with the rest of the remote
Andrew> protocol - GDB initiates the transaction.

Andrew> I think it is possible to modify an existing GDB so that it
Andrew> will behave this way.  It would probably rely on ``remote
Andrew> *async'' as remote.c would need to block on both the console
Andrew> and the target.

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.

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.

        --jtc

-- 
J.T. Conklin
RedBack Networks