From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Salter <msalter@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: gdb/remote - I/O
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <200103261830.f2QIU2614825@deneb.localdomain>
References: <3ABBDDE4.7C22709D@cygnus.com>
X-SW-Source: 2001-03/msg00289.html

>>>>> Andrew Cagney writes:

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


Andrew,

>From a target-side perspective, I'd like to see this as something like:

-> c (continue)
> 	<- T<sigint> (1)
-> i<input>
> 	<- OK
-> c (continue)
> 	.....

(1) Also extended somehow to include indication that target wants
    input and the max size of the input desired.

This eliminates the need for interrupt/Ctrl-C support in the stub.
I've certainly written stubs for boards that didn't have interrupts
on the debug channel and boards which used an NMI button on the board
for that purpose.

It also explicitly tells gdb whether or not the stub supports input
and provides some flow control by having the target tell gdb how
much input it can handle.

Finally, for stubs which do support input, not all apps will want
to use that mechanism and pushing data from the gdb side would
be disruptive for such apps.

--Mark