From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30019 invoked by alias); 14 Apr 2014 18:52:13 -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 30007 invoked by uid 89); 14 Apr 2014 18:52:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com 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, 14 Apr 2014 18:52:11 +0000 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 s3EIq9qG006489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Apr 2014 14:52:09 -0400 Received: from barimba (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3EIq8bo031581 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Apr 2014 14:52:09 -0400 From: Tom Tromey To: Pedro Alves Cc: Andrew Pinski , "gdb-patches\@sourceware.org" Subject: Re: RFC: fix PR backtrace/15558 References: <87li6nghhz.fsf@fleche.redhat.com> <51B11E66.70102@redhat.com> <87mwqjw613.fsf@fleche.redhat.com> <87ha5vrdki.fsf@fleche.redhat.com> <534C2C19.1010503@redhat.com> Date: Mon, 14 Apr 2014 18:52:00 -0000 In-Reply-To: <534C2C19.1010503@redhat.com> (Pedro Alves's message of "Mon, 14 Apr 2014 19:42:33 +0100") Message-ID: <87tx9vpwvb.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-04/txt/msg00281.txt.bz2 Tom> I never got back to fixing it according to Pedro's review. Tom> As I recall it isn't entirely trivial because for a good fix one would Tom> need to expose some new Python methods for use by the frame filter code. Pedro> Hmm. Not sure what you're thinking of. There's a good chance I'm confusing it with some other approach I'd considered. Pedro> We discussed auditing all Pedro> get_prev_frame uses and see if they are better replaced by Pedro> get_prev_frame_1, but I don't think that should hold back Pedro> fixing the inline frame unwinder. Ok. I think what I was thinking is that if one starts this change, then the question arises: which should the Python unwinder call? Calling the user-facing one is plainly incorrect. But, calling the internal one is also incorrect, as some termination conditions may be skipped. Perhaps this only applies if we move all the checks into get_prev_frame_1. I don't recall whether that was part of the plan or not. Tom