This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch][python] 0 of 5 - Frame filters and Wrappers
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 30 Nov 2012 14:30:43 +0000
- Subject: [patch][python] 0 of 5 - Frame filters and Wrappers
This patch introduces the concept of frame filters, and frame wrappers
to GDB. This is a Python API that enables users to filter, sort,
elide and decorate frames that some GDB commands produce.
The commands affected are:
* backtrace command
* -stack-list-frames
* -stack-list-locals
* -stack-list-arguments
* -stack-list-variables
Note the MI commands have to be enabled with the -enable-frame-filters
command first. This is because we include a new field called
"children" in some situations.
This patch is split up into several sections due to its length. Each
patch email has a subject line indicating the contents of that patch.
In total, there are five patch emails, not including this one.
Non Python enabled GDB
======================
If your GDB build is configured not to build the Python API, then
there will be no changes visible to you. GDB backtraces will be
printed as they always have.
Python enabled GDB
==================
In the case of a Python enabled GDB, each command has a switch to turn
off frame filters*, and MI has to have frame filters enabled
explicitly first. I have not provided a CLI command to turn off the
feature on a one-time-basis, but will if it is deemed necessary.
* Frame filters on individual MI commands are turned off with
--no-frame-filters. With the "bt" command, they are turned off with
the raw sub-command (e,g "bt raw"). This is inconsistent at the
moment, and I expect it will be resolved in review. "raw" is
overloaded, but I am at a loss to what to call the sub-command. MI is
easy as it is a machine interface, so length of the option is not an
issue.
Notes
=====
* Printing
My original approach was to create dummy frames from the original
frames and decorating objects, and print those via the existing CLI
routines. However this brought up a number of issues. Creating
dummy frames and printing them disrupts the integrity of the call
stack, and affects how frame navigation is performed (IE, select, or
in the case of Python gdb.selected_frame, gdb.newest_frame, and so
on). Also creating fully coherent and operating dummy frames, with
their associated architectures, registers, and other ancillary
structures turned out to be incredibly complex. I decided instead
to approach the problems as "a frame and a decorator object"
approach. This would have still allowed some use of code, but the
ongoing practice of avoiding stubbing in: #ifdef HAVE_PYTHON into
the non-Python areas of GDB code indicates we should do that as
little and sparingly as possible. So I just decided to write the
routines in the Python section of the GDB codebase.
* Python errors when printing?
Right now if there is an error encountered, the frame printing is
aborted and GDB falls back to its own inbuilt printing routines.
This is up for debate, and I hope it sparks a discussion. If the
GDB Python API encounters an error while printing a backtrace,
should it:
- Abandon the whole backtrace, and have the existing GDB code
print it;
- Abandon that frame, and continue on;
* Shipping frame filters
The current frame filter code will not trigger a Python enabled
frame filter produced backtrace if there are no frame filters
registered. In this case it just defers to the existing GDB frame
printing code. As there are no Python-written frame filters shipped
with FSF GDB, this will be the default case. And if there ever are
any, they will be subject to the usual review policy.
Cheers,
Phil