From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13040 invoked by alias); 17 Sep 2013 18:39:40 -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 4420 invoked by uid 89); 17 Sep 2013 18:37:02 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Sep 2013 18:37:02 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8HIauaI028103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 14:36:57 -0400 Received: from barimba (ovpn-113-63.phx2.redhat.com [10.3.113.63]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8HIatQG001249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Sep 2013 14:36:56 -0400 From: Tom Tromey To: Pedro Alves Cc: Sergio Durigan Junior , Pierre Muller , "'GDB Patches'" Subject: Re: [RFC/PATCH] New convenience variable $_exitsignal References: <00db01ce6b24$0b716aa0$22543fe0$@muller@ics-cnrs.unistra.fr> <52374823.4010203@redhat.com> Date: Tue, 17 Sep 2013 18:39:00 -0000 In-Reply-To: <52374823.4010203@redhat.com> (Pedro Alves's message of "Mon, 16 Sep 2013 19:04:19 +0100") Message-ID: <87bo3rxpko.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-09/txt/msg00537.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> I can't say I really understand how any of that argues against my Pedro> original rationale for not setting $_exitsignal on corefiles (because Pedro> the inferior has not really exited at the point the core has been Pedro> generated), rather than point at implementation choices. Pedro> Now, if one were to instead argue that _user interface_ -wise, it'd Pedro> make sense to set $_exitsignal, because we also print Pedro> "Program terminated with signal", (emphasis on "terminated"), then Pedro> I'd agree: I may have missed part of the thread, but what is the rationale for being so precise here? It seems a bit pedantic to me -- which is fine if there is a purpose to it, but I couldn't think of one in this case. That is, gdb has a bit of information that is relevant to the user. It is useful to users if we expose it to them in a script-friendly way. We already have $_exitsignal, and differentiating between "the program exited with signal X" and "the program is about to exit with signal X" doesn't seem particularly handy. 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. Tom