From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10630 invoked by alias); 17 Sep 2013 19:02:51 -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 10603 invoked by uid 89); 17 Sep 2013 19:02:51 -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 19:02:51 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 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-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 r8HJ2j1Y013469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 15:02:46 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8HJ2hfK004178; Tue, 17 Sep 2013 15:02:44 -0400 Message-ID: <5238A753.4070409@redhat.com> Date: Tue, 17 Sep 2013 19:02: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: Tom Tromey 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> <87bo3rxpko.fsf@fleche.redhat.com> In-Reply-To: <87bo3rxpko.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00543.txt.bz2 On 09/17/2013 07:36 PM, Tom Tromey wrote: >>>>>> "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. Well, guess you've missed it, because from the beginning I had already introduced that as pedantic: https://sourceware.org/ml/gdb-patches/2013-06/msg00337.html Also, if you read downthread, you'll notice that I have agreed to being lax here, just not the presented rationale for it. If we're deciding to set the flag for cores, then IMO, it's important such decisions are conscientiously based on a user interface decisions, not of the style "I think it'd make sense, but I'd have to do such and such". > 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. Consider non-stop, and using gcore for snapshotting the program state. There's no termination/exit at all. In fact, there's are potentially many threads in the program, and each of them, if stopped, should have its own signal number. You should be able to get at all of them with $_siginfo.si_signo, but it's just that older kernels don't have that info. Let's pretend kernels did always write NT_SIGINFO. Would we be arguing for making $_exitsignal work for cores, given that $si_siginfo.si_signo would work? It's plausible. And that's why I'm not against this at all. I just wanted to make sure that design decision is use-case driven, rather than because on Linux's current implementation such-and-such happens. IOW, I wanted that to be recorded on the archives, so if even if the core formats change in the future, we can refer back to today's decisions. > 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. I see, thanks. Sounds reasonable. -- Pedro Alves