From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2657 invoked by alias); 13 Jun 2008 17:34:46 -0000 Received: (qmail 2640 invoked by uid 22791); 13 Jun 2008 17:34:45 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Jun 2008 17:34:24 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m5DHYEsa004185; Fri, 13 Jun 2008 12:34:21 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 12:34:24 -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: Re: Multiprocess MI extensions Date: Fri, 13 Jun 2008 17:34:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA042911CB@ecamlmw720.eamcs.ericsson.se> In-Reply-To: A From: "Marc Khouzam" To: "Vladimir Prus" , 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/msg00143.txt.bz2 > >> -> How to report process exit? Should we overload=20 > =3Dthread-exited, introduce > >> =3Dthread-group-exited, or what? > >> > >> -> Should we auto-attach to newly forked processes? Should we have > >> =3Dnew-thread-group notificatin, if so? > >>=20=20=20 > > Auto attach should probably be an option, but if there is an auto > > attach, a notification should definitely be generated. >=20 > OK. >=20 > >> -> Should we have just =3Dcreated and =3Dexited notifications,=20 > used for threads > >> and processes and what not? > >>=20=20=20 > > I don't think it makes much difference whether the same=20 > event is used or > > not as long as a parent-id field is included in the event. >=20 > Just to make sure we're on the same page -- if we use one=20 > notification for everything, > it will either have a 'thread' field -- when a thread is=20 > created/exited, or 'thread-group' > field, when process is created/exited. Is that OK? Currently, when the inferior exits, there is an event that looks like: *stopped,reason=3D"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. What notification would be used for single-process, after the multi-process changes? Still *stopped... or will it be made in-line with multi-process? Thanks marc