From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24428 invoked by alias); 23 Jul 2010 17:33:56 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 24413 invoked by uid 22791); 23 Jul 2010 17:33:55 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Fri, 23 Jul 2010 17:33:00 -0000 From: Oleg Nesterov To: Roland McGrath Cc: archer@sourceware.org Subject: Re: Q: multiple inferiors, all-stop && vCont Message-ID: <20100723173134.GA29717@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100721170400.GA30978@redhat.com> <20100721204203.D040C400B6@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721204203.D040C400B6@magilla.sf.frob.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00059.txt.bz2 On 07/21, Roland McGrath wrote: > > > 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. OK. I'll try to send something more or less working on Monday. I guess, non-stop mode is more interesting/important than all-stop. Oleg.