From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11685 invoked by alias); 16 Sep 2013 18:04:29 -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 11672 invoked by uid 89); 16 Sep 2013 18:04:29 -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; Mon, 16 Sep 2013 18:04:29 +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-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8GI4MwS011187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Sep 2013 14:04:22 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r8GI4KtH009839; Mon, 16 Sep 2013 14:04:20 -0400 Message-ID: <52374823.4010203@redhat.com> Date: Mon, 16 Sep 2013 18:04: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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00458.txt.bz2 On 06/19/2013 05:59 AM, Sergio Durigan Junior wrote: > 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. Looks like I completely missed this email. Sorry about that. > 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. Really? That's ......, to say the least. ;-) Actually, in my 3.9.10-100.fc17.x86_64 kernel (Fedora 17), what I see is that the kernel only generates the NT_SIGINFO note for the thread that actually crashed. Hmm, actually, for a program with 3 threads, that has one thread call abort, I get: $ readelf -n ~/gdb/tests/threads-crash.core.32195 Displaying notes found at file offset 0x000005f0 with length 0x00001998: Owner Data size Description CORE 0x00000150 NT_PRSTATUS (prstatus structure) CORE 0x00000088 NT_PRPSINFO (prpsinfo structure) CORE 0x00000080 NT_SIGINFO (siginfo_t data) CORE 0x00000130 NT_AUXV (auxiliary vector) CORE 0x000002aa NT_FILE (mapped files) ... CORE 0x00000200 NT_FPREGSET (floating point registers) LINUX 0x00000340 NT_X86_XSTATE (x86 XSAVE extended state) CORE 0x00000150 NT_PRSTATUS (prstatus structure) CORE 0x00000200 NT_FPREGSET (floating point registers) LINUX 0x00000340 NT_X86_XSTATE (x86 XSAVE extended state) CORE 0x00000150 NT_PRSTATUS (prstatus structure) CORE 0x00000200 NT_FPREGSET (floating point registers) LINUX 0x00000340 NT_X86_XSTATE (x86 XSAVE extended state) Which kind of makes sense, given the other threads didn't actually get any signal. > 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. 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. 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)); } -- Pedro Alves