Re: gdb/remote - I/O

[Stephane Carrez <Stephane dot Carrez at Sun dot COM>]

Hi Andrew,

>Hello,
>
>The existing remote protocol doesn't support input vis: GDB -> target
>(ignoring the ``target cisco'' hack that just sends raw characters).  I
>think the current semantics for output are also weak and I'd like to
>change them.  In the below I'll try to sketch out the basic idea.

Yes, Input/output is not handled in a good way for remote targets.
This is true also for monitors (:-

For ChorusOS I solved that by introducing our console management within
the GDB ChorusOS remote target.  If we could have something more generic,
or re-usable at target/monitor level, this would help.


> [...]
>
>
>The output mechanism is treated like any other continue response.  That
>is, it halts the target and waits for further input vis:
>
>	-> c (continue)
>	<- o<output> (implied halt)
>	-> c (continue)
>	<- o<more-output> (implied halt)
>	-> c (continue)
>	<- T... (stop)
>
>
>Pragmatics:
>
>It makes the behavour consistent with the rest of the remote protocol.
>
>The additional round trip is acceptable since the objective is to
>implement a primative but (relativly) reliable console.  The objective
>is not to implement a high speed data link.
>
>It is possible to implement this in the existing GDB without significant
>change.
>

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


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.

>
>Input:
>
>For input, GDB would first get the targets attention (<BREAK>) then pass
>down the input and finally resume the target vis:
>
>	-> c (continue)
>	<BREAK>
>	<- T<sigint> (stop)
>	-> i<input>
>	<- OK
>	-> c (continue)
>	.....
>	<- T.... (stop)
>
>A refinement might see:
>
>	-> c (continue)
>	<BREAK>
>	<- T<sigint> (stop)
>	-> c<input> (continue with input)
>	....
>	<- T.... (stop)
>
>Pragmatics:
>
>It is slow, oops!  The objective is to implement a functional console,
>not a fast console :-)
>
>The interaction is consistent with the rest of the remote protocol - GDB
>initiates the transaction.
>
>I think it is possible to modify an existing GDB so that it will behave
>this way.  It would probably rely on ``remote *async'' as remote.c would
>need to block on both the console and the target.
>
>Unlike other implementations this doesn't involve making the protocol
>asynchronous.  Consequently, it should keep the target simpler.
>
>Flow control is a target problem.  That data gets sent across, ready or
>not :-)
>
>	thoughts,
>		Andrew

Agree.  This is how ChorusOS DebugAgent/DebugServer cooperate for the input.

In this direction, the performance is less important.  In general you
expect more outputs than inputs.

Cheers,
	Stephane

-	-	-	-	-	-	-	-	-	-
Stephane |Sun Microsystems			|
 Carrez	 |Network Service Provider Division	| http://www.sun.com
	 |6 avenue Gustave Eiffel		|
	 |F-78182, St-Quentin-en-Yvelines-Cedex |

email: Stephane.Carrez@France.Sun.COM