From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7746 invoked by alias); 17 Jun 2008 18:32:32 -0000 Received: (qmail 7738 invoked by uid 22791); 17 Jun 2008 18:32:31 -0000 X-Spam-Check-By: sourceware.org Received: from mailgw3.ericsson.se (HELO mailgw3.ericsson.se) (193.180.251.60) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Jun 2008 18:32:09 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B111A20964; Tue, 17 Jun 2008 20:32:05 +0200 (CEST) X-AuditID: c1b4fb3c-ad89abb00000193b-e7-485803259999 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9481B20975; Tue, 17 Jun 2008 20:32:05 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 20:32:13 +0200 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 20:32:13 +0200 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 13:32:07 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiprocess MI extensions Date: Tue, 17 Jun 2008 18:32:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA042911E1@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200806141915.49678.vladimir@codesourcery.com> From: "Marc Khouzam" To: "Vladimir Prus" Cc: X-IsSubscribed: yes 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/msg00166.txt.bz2 > > Currently, when the inferior exits, there is an event that=20 > looks like: > > *stopped,reason=3D"exited-normally" > > or some other variant. > >=20 > > I gather this is not a considered option for multi-process? > > It probably would have helped with backwards compatibility. >=20 > I don't know, honestly. Is extending *stopped with=20 > 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). 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. 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.=20=20 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? Thanks Marc