From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16491 invoked by alias); 17 Sep 2013 16:19:11 -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 16480 invoked by uid 89); 17 Sep 2013 16:19:11 -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 16:19:11 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8HGJ5rU011025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 12:19:05 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8HGJ3jG010378; Tue, 17 Sep 2013 12:19:03 -0400 Message-ID: <523880F6.7030900@redhat.com> Date: Tue, 17 Sep 2013 16:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sergio Durigan Junior CC: 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00518.txt.bz2 On 09/17/2013 01:11 AM, Sergio Durigan Junior wrote: >> I can't say I really understand how any of that argues against my >> original rationale for not setting $_exitsignal on corefiles (because >> the inferior has not really exited at the point the core has been >> generated), rather than point at implementation choices. > > Interesting. I thought setting it made sense because it seems to me > that the inferior has exited when the corefile has been generated. I am > clearly missing some knowledge here, then... Then that's what you need to argue. ;-) My point of view was that when inspecting a core dump, you're seeing the state of the program _before_ it exited. E.g, if you stop the program (with a breakpoint, ctrl-c, or even "interrupt -a"/non-stop), do "gcore", and then debug the resulting core, the program never exited. >> Now, if one were to instead argue that _user interface_ -wise, it'd >> make sense to set $_exitsignal, because we also print >> "Program terminated with signal", (emphasis on "terminated"), then >> I'd agree: >> >> siggy = bfd_core_file_failing_signal (core_bfd); >> if (siggy > 0) >> { >> ... >> printf_filtered (_("Program terminated with signal %s, %s.\n"), >> gdb_signal_to_name (sig), gdb_signal_to_string (sig)); >> } > > ...or not. Apparently, you are differentiating between "exited" and > "terminated", right? Could you expand a little more on this? No, not differentiating. The emphasis was for pointing out that GDB already claims the program has indeed terminated, so from that perspective, it does indeed make sense to set $_exitsignal, otherwise, to make things consistent, _I_, in turn, would need to argue for removing that "Program terminated with signal" message. I don't plan to, so I get to agree with setting $_exitsignal. See, this is all about _user interface_, not random internal implementation choices, which will naturally change over time, but the user interface design decision will most probably outlast that for a long while. > And BTW, I guess my reasoning for setting $_exitsignal here is indeed > because we already assume that the inferior has been terminated (or > exited?) indeed. Thanks, -- Pedro Alves