Re: gdb/remote - I/O

[jtc@redback.com (J.T. Conklin)]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

Frank> jtc wrote:
Frank> : Question: Does the remote protocol support systems where
Frank> : other threads continue to execute when one being debugged is
Frank> : halted.  [...] But does the protocol itself allow this?  From
Frank> : what I can tell, it can.  If it does not, it almost does ---
Frank> : especially when you consider how loosely some of the commands
Frank> : are defined.

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

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

The reason I asked is that from time to time over the last few years,
there has been talk of enhancing GDB to use a more complicated model
where systems with multiple (possibly heterogenous) processors, each
with multiple processes, each with multiple threads could be debugged.
If this is still the goal, we need to consider whether each decision
we make takes us closer or precludes us from reaching the goal.

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

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

With this model, you might be connected to the target (thus be able to
handle I/O) but not attached to any one thread.  I've debugged vxWorks
targets this way, where the system is free running and all I can do is
memory reads and writes.  This loses if I/O can only be handled while
waiting for an inferior thread/process.

        --jtc

-- 
J.T. Conklin
RedBack Networks