This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch][python] 0 of 5 - Frame filters and Wrappers
- From: Tom Tromey <tromey at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: "gdb-patches\ at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 03 Dec 2012 14:34:30 -0700
- Subject: Re: [patch][python] 0 of 5 - Frame filters and Wrappers
- References: <50B8C313.2070404@redhat.com>
>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> 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?
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.
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.
Tom