From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18567 invoked by alias); 21 Jun 2013 20:41:33 -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 18552 invoked by uid 89); 21 Jun 2013 20:41:32 -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; Fri, 21 Jun 2013 20:41:31 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5LKfUgs024621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Jun 2013 16:41:30 -0400 Received: from barimba (ovpn-113-102.phx2.redhat.com [10.3.113.102]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5LKfSQm028684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Jun 2013 16:41:29 -0400 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFC: fix PR backtrace/15558 References: <87li6nghhz.fsf@fleche.redhat.com> <51B11E66.70102@redhat.com> Date: Fri, 21 Jun 2013 21:21:00 -0000 In-Reply-To: <51B11E66.70102@redhat.com> (Pedro Alves's message of "Fri, 07 Jun 2013 00:42:30 +0100") Message-ID: <87mwqjw613.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-06/txt/msg00625.txt.bz2 Pedro> Yeah, I was suggesting that "internal" / non-user-facing code Pedro> should not be using get_prev_frame, but get_prev_frame_1 instead, Pedro> bypassing all the checks. (Or rather wondering why that isn't Pedro> so). Strongly more so in an unwinder's innards. get_prev_frame Pedro> uses need to be investigated on a case-by-case manner manner to Pedro> decide the best course of action, IMO. I agree from a design standpoint that this is superior. My main concern is that I am not confident that all the unwinders in the tree actually stop sanely. If we believe that they do then it seems straightforward to do the split as you suggest. Normally I don't like to code to work around potential bugs elsewhere. However in some parts of gdb, like this one, it is difficult to do otherwise, due to the testing problem. Anyway, this is why I split the function where I did. Pedro> So conceptually, in this case, I think what makes most sense it Pedro> to skip _all_ the checks in get_prev_frame* that might return Pedro> NULL, as there should always be a prev frame for an inline frame. Pedro> IOW, in this case, I believe we should be making Pedro> inline_frame_this_id call get_prev_frame_1, or whatever it gets Pedro> renamed to, or equivalent. That sounds reasonable. I'll rework the patch next week. Tom