This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch][python] 0 of 5 - Frame filters and Wrappers


Version 2


Here is an updated patch from review discussion and requests

--


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]