From mboxrd@z Thu Jan 1 00:00:00 1970 From: fche@redhat.com (Frank Ch. Eigler) To: jtc@redback.com Cc: GDB Discussion Subject: Re: gdb/remote - I/O Date: Sat, 07 Apr 2001 16:02:00 -0000 Message-id: References: <3ABBDDE4.7C22709D@cygnus.com> <3ACE0AD6.913C9A94@cygnus.com> <3ACE0E6B.CF3C9A2B@redhat.com> <5md7apvm4c.fsf@jtc.redback.com> X-SW-Source: 2001-04/msg00061.html 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