From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32053 invoked by alias); 5 Dec 2012 12:31:36 -0000 Received: (qmail 32039 invoked by uid 22791); 5 Dec 2012 12:31:33 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Dec 2012 12:31:26 +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 qB5CVQex017676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Dec 2012 07:31:26 -0500 Received: from localhost.localdomain (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qB5CVP4I016032; Wed, 5 Dec 2012 07:31:25 -0500 Message-ID: <50BF3E9D.4080403@redhat.com> Date: Wed, 05 Dec 2012 12:31:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Tom Tromey CC: "gdb-patches@sourceware.org" Subject: Re: [patch][python] 0 of 5 - Frame filters and Wrappers References: <50B8C313.2070404@redhat.com> <87k3syvmzd.fsf@fleche.redhat.com> In-Reply-To: <87k3syvmzd.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2012-12/txt/msg00071.txt.bz2 On 12/03/2012 09:34 PM, Tom Tromey wrote: >>>>>> "Phil" == Phil Muldoon writes: > > Phil> * Frame filters on individual MI commands are turned off with > Phil> --no-frame-filters. With the "bt" command, they are turned off with > Phil> the raw sub-command (e,g "bt raw"). This is inconsistent at the > Phil> moment, and I expect it will be resolved in review. > > What is it that is inconsistent? Just the naming. With MI, because it is a machine interface, option length is not so important. So --no-frame-filters in the MI command turns off a specific feature. However, "raw" in the "bt" command does not turn off a specific function, or is ambiguous. I would really like to think of an option name that is small enough not to be painful to type, but meaningful and specific. I could not, so I just highlighted it in the review. > > Phil> * Python errors when printing? > Phil> Right now if there is an error encountered, the frame printing is > Phil> aborted and GDB falls back to its own inbuilt printing routines. > Phil> This is up for debate, and I hope it sparks a discussion. If the > Phil> GDB Python API encounters an error while printing a backtrace, > Phil> should it: > > Phil> - Abandon the whole backtrace, and have the existing GDB code > Phil> print it; > > Phil> - Abandon that frame, and continue on; > > Considering that frame-printing is lazy, I think it would be weird to > try to abandon the whole backtrace and start over. E.g., suppose the > error occurred after already displaying the first 5 frames -- starting > over would show pretty confusing output. > > Whether to keep going, I am not sure. Well there are two steps. The actual filtering, this occurs when frame filters operate on the frame iterator. Errors can occur here, though I suppose the scope for that is considerably narrower than in the printing phase. If an error occurs in this phase I think (though the patch does not do this right now), we abandon the stack trace with an error message of the name of the erroring filter, and defer to GDB's inbuilt backtrace. For both MI and CLI. As no frames have been printed yet, this would be fairly clear. At the printing step this is a different issue. At this point all of the frame filters have executed. Now the Python code is printing out the backtrace frame-by-frame with its own built-in routines according to how each frame wrapper decorates each frame. I think an error with the frame wrapper as you suggested, then moving onto the next frame is probably best here? > When printing an error from a Python printer, it would be very nice for > gdb to tell the user how to disable that particular printer. I think > this ought to be pretty easy. Yeah, good idea. Cheers, Phil