From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16129 invoked by alias); 17 Sep 2013 19:09:24 -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 16120 invoked by uid 89); 17 Sep 2013 19:09:24 -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:09:24 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8HJ9Jxm014838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 15:09:19 -0400 Received: from barimba (ovpn-113-63.phx2.redhat.com [10.3.113.63]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8HJ9Iar013891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Sep 2013 15:09:19 -0400 From: Tom Tromey To: Pedro Alves 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> <5238A753.4070409@redhat.com> Date: Tue, 17 Sep 2013 19:09:00 -0000 In-Reply-To: <5238A753.4070409@redhat.com> (Pedro Alves's message of "Tue, 17 Sep 2013 20:02:43 +0100") Message-ID: <87d2o7w9i9.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-09/txt/msg00545.txt.bz2 Pedro> Well, guess you've missed it, because from the beginning I had already Pedro> introduced that as pedantic: Thanks. Pedro> Consider non-stop, and using gcore for snapshotting the program Pedro> state. There's no termination/exit at all. In fact, there's are Pedro> potentially many threads in the program, and each of them, if Pedro> stopped, should have its own signal number. You should be able Pedro> to get at all of them with $_siginfo.si_signo, but it's just that Pedro> older kernels don't have that info. Let's pretend kernels did Pedro> always write NT_SIGINFO. Would we be arguing for making Pedro> $_exitsignal work for cores, given that $si_siginfo.si_signo Pedro> would work? It's plausible. And that's why I'm not against this Pedro> at all. I just wanted to make sure that design decision is Pedro> use-case driven, rather than because on Linux's current Pedro> implementation such-and-such happens. IOW, I wanted that to be Pedro> recorded on the archives, so if even if the core formats change Pedro> in the future, we can refer back to today's decisions. Thanks, that is a nice summary for those of us who lost track. Which may just be me, but still. Also, let me say that I continue to find it delightful how you have all the hard cases at hand, ready to roll out over my simplistic arguments :-) >> 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. Pedro> I see, thanks. Sounds reasonable. I see now from your explanation that the cases are in fact different. The "catch exit" case is more clearly a direct mapping. Tom