From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31753 invoked by alias); 18 Jun 2008 08:39:02 -0000 Received: (qmail 31745 invoked by uid 22791); 18 Jun 2008 08:39:01 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Jun 2008 08:38:44 +0000 Received: (qmail 7862 invoked from network); 18 Jun 2008 08:38:42 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jun 2008 08:38:42 -0000 From: Vladimir Prus To: "Marc Khouzam" Subject: Re: Multiprocess MI extensions Date: Wed, 18 Jun 2008 08:39:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb@sources.redhat.com References: <6D19CA8D71C89C43A057926FE0D4ADAA042911E1@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA042911E1@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181238.44911.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00176.txt.bz2 On Tuesday 17 June 2008 22:32:06 Marc Khouzam wrote: > > > > Currently, when the inferior exits, there is an event that > > looks like: > > > *stopped,reason="exited-normally" > > > or some other variant. > > > > > > I gather this is not a considered option for multi-process? > > > It probably would have helped with backwards compatibility. > > > > I don't know, honestly. Is extending *stopped with > > thread-group field really > > much better for backward compatibility that new notification? > > I had imagined to make multi-process debugging the only variant, which > would makes a single-process session actually be a multi-process one > with a single process (or thread-group). This is the ultimate goal. > But what we can do is look for both the new notification for process exit > and the *stopped one, which ever _one_ we see, will be the trigger. > So, as long as we get one or the other but not both at the same time, > it should be fine. I need to think about this more -- I just don't know what's the right thing here. > On another point for multi-process, I was wondering if there will be a need > to select a thread-group before issuing commands affecting a entire > group? Something similar to what we have with -thread-select. > I was thinking that a command affecting a group would apply to the group > to which the current thread belongs. > > This would allow for any command currently applicable to the single process > or inferior, to be applied in the same way. To be honnest, I'm not entirely > sure this is a good idea. > > Did you guys discuss this? Not so much as "discuss". I personally try to avoid introducing more state in MI, at all costs. That's why for commands wishing to operate on a given thread group, the --thread-group option will be required. Presently, only -exec-continue and -exec-interrupt seem to need this, though. - Volodya