Re: gdb/remote - I/O

J.T. Conklin
2001-04-06T12:56:00Z

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