This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb/remote - I/O
- To: ac131313 at cygnus dot com
- Subject: Re: gdb/remote - I/O
- From: Mark Salter <msalter at redhat dot com>
- Date: Mon, 26 Mar 2001 13:30:02 -0500
- CC: gdb at sources dot redhat dot com
- References: <3ABBDDE4.7C22709D@cygnus.com>
>>>>> 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