Re: gdb/remote - I/O

[Mark Salter <msalter at redhat dot com>]

>>>>> Andrew Cagney writes:

> Mark Salter wrote:
>> 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.

> Wants or is able to accept input?

It could be both if needed.

> What should GDB do if there is no input available?

Continue the target. The target can repeat until it gets what it
needs.

The flip side of this is what to do if input is available, but
the target doesn't ask for it because it stopped for some other
reason.

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

> Good point.

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

> So you're suggesting a polling mechanism?

Yes. The main reasons are (in no particular order):

  o Eliminate requirement for interrupts on the debug channel.

  o Prevent unnecessary interruptions when target doesn't want input.

  o Prevent buffer overflow on the target side.

I guess the first two are closely related.

--Mark