Re: gdb/remote - I/O

[fche at redhat dot com (Frank Ch. Eigler)]

jtc wrote:

: [...]
: Question: Does the remote protocol support systems where other threads
: continue to execute when one being debugged is halted.  [...] 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.

While the wire protocol is indeed rather loose, the process model
assumed by the dominant party (gdb) should be respected.  I would
ascribe looseness not to encouraging creative implementations, but to
systemic lack of formality.

If your target requires some mixed halted/running thread states, and
you run into problems with gdb's model, you could consider switching
to a multi-process rather than multi-thread debugging model.


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

Is there anything special about I/O in this way?  If your unusual
target, when responding to a ^C/break from gdb, decides to stop just
one thread, it could do the same thing for I/O.  It could suspend the
output-causing thread; it could suspend any old thread for enqueueing
input.


- FChE