gdb/remote - I/O

[Andrew Cagney <ac131313 at cygnus dot com>]

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.

As way of background, the remote protocol is not symetric.  GDB
initiates everything and then the target (eventually) responds.  For
instance:

	-> g (read registers)

	<- 12345678123456781234567812345678
	   (register bytes in hex)

A target is continued with:

	-> c (continue)

	(time passes)

	<- T....
	   (stop with info)

To halt the target:

	-> c (continue)
	(time passes)
	<BREAK>
	(time passes)
	<- T.... (stop)

Where <BREAK> is the CNTRL-C character but could be some other
out-of-band character.
Appart from the ``O'' (output) packet, the target never initiates
anything.


Output:

I'd like to change the protocol so that the output mechanism is
synchronous.  That is, instead of:

	-> c (continue)
	<- O....  (hex output)
	<- O....  (more hex output)
	<- T... (stop)

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.


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