From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12486 invoked by alias); 21 Jul 2010 20:42:14 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 12473 invoked by uid 22791); 21 Jul 2010 20:42:13 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov Cc: archer@sourceware.org Subject: Re: Q: multiple inferiors, all-stop && vCont In-Reply-To: Oleg Nesterov's message of Wednesday, 21 July 2010 19:04:00 +0200 <20100721170400.GA30978@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100721170400.GA30978@redhat.com> Message-Id: <20100721204203.D040C400B6@magilla.sf.frob.com> Date: Wed, 21 Jul 2010 20:42:00 -0000 X-SW-Source: 2010-q3/txt/msg00058.txt.bz2 > I am trying to undestand what ugdb should know about the multiple > inferiors. Looks like, I shouldn't worry at all. They do not exist > from gdbserver's pov. It should handle the multiple attach/detach, > of course, but that is all. Say, qsThreadInfo should list all > attached threads in random order. IOW, there is no any command > which can refer to any particular inferior somehow, explicitly or > implicitly. Only THREAD-ID can matter. I'm not sure what the story on gdb's multi-process support is and how that relates to remote protocol details. It's fine to start out by only worrying about being attached to a single process with all its threads. Certainly we want to be handling multiple processes well at some point, so don't structure things so it would be especially difficult. But it is probably the case that representing that notion on the remote protocol is all a bit of a muddle, and you shouldn't worry about resolving that before moving ahead. > So. Reference to actual practice doesn't help, I suspect it is buggy. Well, actual practice of rarely-used features, anyway. Multi-process is newfangled and apparently quite unreliable. Single-process, multi-thread is what is used a lot. Thanks, Roland