From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24448 invoked by alias); 17 Sep 2013 00:11:28 -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 24439 invoked by uid 89); 17 Sep 2013 00:11:28 -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 00:11:28 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,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 r8H0BKl7008768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Sep 2013 20:11:20 -0400 Received: from psique (ovpn-113-38.phx2.redhat.com [10.3.113.38]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r8H0BGwd008476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 16 Sep 2013 20:11:18 -0400 From: Sergio Durigan Junior To: Pedro Alves 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> X-URL: http://www.redhat.com Date: Tue, 17 Sep 2013 00:11:00 -0000 In-Reply-To: <52374823.4010203@redhat.com> (Pedro Alves's message of "Mon, 16 Sep 2013 19:04:19 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00480.txt.bz2 On Monday, September 16 2013, Pedro Alves wrote: > 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. No problem, I forgot about it as well, and I wrote it mostly to keep my opinions recorded. Glad you replied to it, though! >> 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. Yes, it does make sense. And it was what I was expecting to see. However, I cannot really remember how I came to the conclusion I wrote above, since I did the same things that you did. >> 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. 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... > 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? 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, -- Sergio