From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22241 invoked by alias); 19 Jun 2013 04:59:34 -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 22229 invoked by uid 89); 19 Jun 2013 04:59:33 -0000 X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 19 Jun 2013 04:59:32 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5J4xRif000382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 00:59:28 -0400 Received: from psique (ovpn-113-144.phx2.redhat.com [10.3.113.144]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5J4xODQ013130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 00:59:26 -0400 From: Sergio Durigan Junior To: "Pierre Muller" Cc: "'GDB Patches'" Subject: Re: [RFC/PATCH] New convenience variable $_exitsignal References: <00db01ce6b24$0b716aa0$22543fe0$@muller@ics-cnrs.unistra.fr> X-URL: http://www.redhat.com Date: Wed, 19 Jun 2013 05:26:00 -0000 In-Reply-To: (Sergio Durigan Junior's message of "Mon, 17 Jun 2013 14:51:52 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-06/txt/msg00474.txt.bz2 On Monday, June 17 2013, I wrote: > On Monday, June 17 2013, Pierre Muller wrote: > >> Hi Sergio, >> >> Is there a reason why you don't handle >> corelow.c anymore in your new patch? > > Hi Pierre, > > Yes, corelow.c is not important to this patch because (as Pedro > explained on > ) > $_exitsignal should not be set for corefiles, because the inferior has > not exited. > > corelow.c will be touched in my next patch, which will add $_signo (but > with the modifications proposed by Pedro). I've been thinking about this answer I gave to Pierre. After investigating how corefiles handle the signal, I guess the right choice would indeed be to set $_exitsignal in corelow.c as well. This is my rationale. 1) Single-threaded program + generate-core-file In this case, NT_SIGINFO will not be filled by GDB's generate-core-file (bug) because PRSTATUS generation does not contemplate that yet (which reminds me of the PRPSINFO work I did few months ago, and the PRSTATUS work I still need to do, which will fix this bug). So, in this case, "print $_siginfo.si_signo" will not display the correct signal, and we can only rely on "bfd_core_file_failing_signal" (called inside corelow.c). Thus, setting $_signo to "bfd_core_file_failing_signal" is the logical choice (of course, if we want to avoid having to use NT_SIGINFO, that is the *only* choice). 2) Single-threaded program + SIGSEGV (or another "Core" signal) In this case, the Linux kernel correctly generates the NT_SIGINFO, which can be displayed by $_siginfo. However, we don't want to use NT_SIGINFO, so "bfd_core_file_failing_signal" is the only choice again. 3) Multi-threaded program + generate-core-file Again, NT_SIGINFO is not generated by GDB. Again, "bfd_core_file_failing_signal" is the only choice. (Back to this case later) 4) Multi-threaded program + SIGSEGV (or another "Core" signal) Linux kernel generated NT_SIGINFO, but we don't want to use it. However, the kernel put in NT_SIGINFO the same signal number (which killed the process) for all threads. Thus, using "bfd_core_file_failing_signal" is OK since there is no concept of "this signal number killed only this thread". Case (3) is the most difficult IMO. I don't know how we are going to handle it when I/we implement NT_SIGINFO generation on PRSTATUS. My first reaction is to do it using the same logic as the Linux kernel, i.e., putting the same signal number in every thread's siginfo. But I don't think we should bikeshed too much now, so I'm stopping my e-mail here. I'd like to hear opinions. Thanks, -- Sergio