From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31684 invoked by alias); 17 Sep 2013 18:53:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 31675 invoked by uid 89); 17 Sep 2013 18:53:20 -0000 Received: from mailrelay012.isp.belgacom.be (HELO mailrelay012.isp.belgacom.be) (195.238.6.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Sep 2013 18:53:20 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.8 required=5.0 tests=AWL,BAYES_20,CK_HELO_DYNAMIC_SPLIT_IP,HELO_DYNAMIC_SPLIT_IP,KHOP_THREADED,SPF_SOFTFAIL,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: mailrelay012.isp.belgacom.be X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBADSkOFJtgOAO/2dsb2JhbAANTYc7uViEIIE0gxkBAQEDASNWBQsLGgImAgJXBogQp3p0kXWBKY4+B4JpgTUDojGKZA Received: from 14.224-128-109.adsl-dyn.isp.belgacom.be (HELO [192.168.1.3]) ([109.128.224.14]) by relay.skynet.be with ESMTP; 17 Sep 2013 20:53:15 +0200 Subject: Re: [RFC/PATCH] New convenience variable $_exitsignal From: Philippe Waroquiers To: Tom Tromey Cc: Pedro Alves , Sergio Durigan Junior , Pierre Muller , 'GDB Patches' In-Reply-To: <87bo3rxpko.fsf@fleche.redhat.com> References: <00db01ce6b24$0b716aa0$22543fe0$@muller@ics-cnrs.unistra.fr> <52374823.4010203@redhat.com> <87bo3rxpko.fsf@fleche.redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 17 Sep 2013 18:53:00 -0000 Message-ID: <1379444008.2222.35.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00538.txt.bz2 On Tue, 2013-09-17 at 12:36 -0600, Tom Tromey wrote: > Another consideration along these lines is that I have a branch in > progress for "catch exit" -- it's been waiting for Sergio's work on > these convenience variables. I think here as well $_exitsignal seems > like a natural fit, even though the process has not technically exited > at the catchpoint. Will there be (significant) functional differences between "catch exit" and "catch syscall exit exit_group" ? Philippe