This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gdb/remote - I/O


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]