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