Re: gdb/remote - I/O

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
Fernando> We do have two different kinds of output coming from the
Fernando> target: output produced by the os/monitor/stub or whatever
Fernando> we are talking to and the output from the application
Fernando> (little bit of semi-hosting).
Fernando>
Fernando> Fortunately for us, they happen at different times.  When
Fernando> the program is running (after run or step) the output can be
Fernando> assumed to be from the program and should go to gdb_stdtarg.
Fernando> When the program is not running the output can only be from
Fernando> the controlling software, and we can send it to gdb_stdout.

I've been thinking about the proposed changes to the remote protocol
since they were first brought up.  I've been trying to come to terms
with an issue myself before I put it up for discussion in a coherent
manner, but since I'm not making much progress on my own I thought I'd
better better share what I've got.

Question: Does the remote protocol support systems where other threads
continue to execute when one being debugged is halted.  This is a hard
question to answer, since the existing implementation of both GDB and
the debug agents (stubs, gdbserver, and I suppose libremote (although
I've never seen it)) assume the target completely stops.  But does the
protocol itself allow this?  From what I can tell, it can.  If it does
not, it almost does --- especially when you consider how loosely some 
of the commands are defined.

The proposals wrt. I/O seem to require the target to halt for I/O,
which precludes enhancing GDB and the debug agents to take full
advantage of the remote protocol.  I ask whether or not this is 
desirable?

        --jtc

-- 
J.T. Conklin
RedBack Networks