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

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

[Phil Muldoon]

Version 4


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.

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

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

[Phil Muldoon]

On 06/05/13 09:22, Phil Muldoon wrote:
> 
> Version 4
> 
> 
> Here is an updated patch from review discussion and requests
> 
> --

This patch-series has been committed in its entirety.  Thank you for
the reviews, it is very much appreciated.  I have attached the
ChangeLog entries as merged for committing the patch.

Cheers,

Phil


2013-05-10  Phil Muldoon  <pmuldoon@redhat.com>

	* stack.c (backtrace_command_1): Add "no-filters", and Python frame
	filter logic.
	(backtrace_command): Add "no-filters" option parsing.
	(_initialize_stack): Alter help to reflect "no-filters" option.
	* Makefile.in (SUBDIR_PYTHON_OBS): Add py-framefilter.o
	(SUBDIR_PYTHON_SRCS): Add py-framefilter.c
	(py-frame.o): Add target
	* data-directory/Makefile.in (PYTHON_DIR): Add Python frame
	filter files.
	* python/python.h: Add new frame filter constants, and flag enum.
	(apply_frame_filter): Add definition.
	* python/python.c (apply_frame_filter): New non-Python
	enabled function.
	* python/py-utils.c (py_xdecref): New function.
	(make_cleanup_py_xdecref): Ditto.
	* python/py-objfile.c: Declare frame_filters dictionary.
	(objfpy_dealloc): Add frame_filters dealloc.
	(objfpy_new): Initialize frame_filters attribute.
	(objfile_to_objfile_object): Ditto.
	(objfpy_get_frame_filters): New function.
	(objfpy_set_frame_filters): New function.
	* python/py-progspace.c: Declare frame_filters dictionary.
	(pspy_dealloc): Add frame_filters dealloc.
	(pspy_new): Initialize frame_filters attribute.
	(pspacee_to_pspace_object): Ditto.
	(pspy_get_frame_filters): New function.
	(pspy_set_frame_filters): New function.
	* python/py-framefilter.c: New file.
	* python/lib/gdb/command/frame_filters.py: New file.
	* python/lib/gdb/frames.py: New file.
	* python/lib/gdb/__init__.py: Initialize global frame_filters
	dictionary
	* python/lib/gdb/FrameDecorator.py: New file.
	* python/lib/gdb/FrameIterator.py: New file.
	* mi/mi-cmds.c (mi_cmds): Add frame filters command.
	* mi/mi-cmds.h: Declare.
	* mi/mi-cmd-stack.c (mi_cmd_stack_list_frames): Add
	--no-frame-filter logic, and Python frame filter logic.
	(stack_enable_frame_filters): New function.
	(parse_no_frame_option): Ditto.
	(mi_cmd_stack_list_frames): Add --no-frame-filter and Python frame
	filter logic.
	(mi_cmd_stack_list_locals): Ditto.
	(mi_cmd_stack_list_args): Ditto.
	(mi_cmd_stack_list_variables): Ditto.
	* NEWS: Add frame filter note.

2013-05-10  Phil Muldoon  <pmuldoon@redhat.com>

	* gdb.python/py-framefilter.py: New File.
	* gdb.python/py-framefilter-mi.exp: Ditto.
	* gdb.python/py-framefilter.c: Ditto.
	* gdb.python/py-framefilter-mi.exp: Ditto.
	* gdb.python/py-framefilter-mi.c: Ditto,
	* gdb.python/py-framefilter-gdb.py.in: Ditto.

2013-05-10 Phil Muldoon  <pmuldoon@redhat.com>

	* gdb.texinfo (Backtrace): Add "no-filter" argument.
	(Python API): Add Frame	Filters API, Frame Wrapper API,
	Writing a Frame Filter/Wrapper,	Managing Management of Frame
	Filters chapter entries.
	(Frame Filters API): New Node.
	(Frame Wrapper API): New Node.
	(Writing a Frame Filter): New Node.
	(Managing Frame Filters): New Node.
	(Progspaces In Python): Add note about frame_filters attribute.
	(Objfiles in Python): Ditto.
	(GDB/MI Stack Manipulation): Add -enable-frame-filters command,
	@anchors and --no-frame-filters option to -stack-list-variables,
	-stack-list-frames, -stack-list-locals and -stack-list-arguments
	commands.

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

[Joel Brobecker]

Hi Phil,

> This patch-series has been committed in its entirety.  Thank you for
> the reviews, it is very much appreciated.  I have attached the
> ChangeLog entries as merged for committing the patch.

There is something I noticed while using a debugger where the gdb
modules cannot be found:

  (gdb) bt
  Python Exception <type 'exceptions.ImportError'> No module named gdb.frames: 

This is because I am using a debugger where python module path relocation
is not working for some reason I am yet to investigate. But this would
happen to someone improperly installing GDB as well.  This can actually
happen fairly often, because it's usual in emergency situations to just
copy the gdb binary where you need it instead of the full blown install,
knowingly letting go of the Python capabilities when you don't need them.

I am wondering whether we might want to be a little more resilient,
in that situation, and fall-back on pretending Python is not available
if the gdb.frames module could not be imported.

-- 
Joel

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

[Phil Muldoon]

On 16/05/13 12:50, Joel Brobecker wrote:
> Hi Phil,
> 
>> This patch-series has been committed in its entirety.  Thank you for
>> the reviews, it is very much appreciated.  I have attached the
>> ChangeLog entries as merged for committing the patch.
> 
> There is something I noticed while using a debugger where the gdb
> modules cannot be found:
> 
>   (gdb) bt
>   Python Exception <type 'exceptions.ImportError'> No module named gdb.frames: 
> 
> This is because I am using a debugger where python module path relocation
> is not working for some reason I am yet to investigate. But this would
> happen to someone improperly installing GDB as well.  This can actually
> happen fairly often, because it's usual in emergency situations to just
> copy the gdb binary where you need it instead of the full blown install,
> knowingly letting go of the Python capabilities when you don't need them.

We can, I have no real opinion.  In a case of an error importing that
module, we can set a flag to turn frame filters off.  While I am
sympathetic, this scenario should never really happen if GDB was
compiled and installed with Python. (Well, obviously it did in your
scenario ;) But that's another bug).

But this I think is the tip of the iceberg with an improperly
installed Python GDB.  I suspect pretty-printing will also suffer
failures, and other automatically instantiated Python bits within GDB.

Anyway, I'll write a patch to be more fault tolerant if nobody else
objects or has a differing opinion.

Cheers,

Phil

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

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> I am wondering whether we might want to be a little more resilient,
Joel> in that situation, and fall-back on pretending Python is not available
Joel> if the gdb.frames module could not be imported.

Yeah, it is a good idea.
I have a patch in the Python series that might help with this, or at
least lay some groundwork.  I'll revisit it soon.

Tom

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

[Tom Tromey]

Phil> Anyway, I'll write a patch to be more fault tolerant if nobody else
Phil> objects or has a differing opinion.

See http://sourceware.org/ml/gdb-patches/2013-04/msg00588.html
for a start.

I was planning to rebase, retest, and commit this series next week.

Tom

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

[Phil Muldoon]

On 16/05/13 14:32, Tom Tromey wrote:
> Phil> Anyway, I'll write a patch to be more fault tolerant if nobody else
> Phil> objects or has a differing opinion.
> 
> See http://sourceware.org/ml/gdb-patches/2013-04/msg00588.html
> for a start.
> 
> I was planning to rebase, retest, and commit this series next week.

That's great.  If this on your schedule, I'll defer to your work and let you rebase etc.

Cheers,

Phil

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

[Tom Tromey]

Phil> Anyway, I'll write a patch to be more fault tolerant if nobody else
Phil> objects or has a differing opinion.

Tom> See http://sourceware.org/ml/gdb-patches/2013-04/msg00588.html
Tom> for a start.

Tom> I was planning to rebase, retest, and commit this series next week.

I've filed a bug for this now:
http://sourceware.org/bugzilla/show_bug.cgi?id=15752

Tom

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

[Phil Muldoon]

Version 3


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.

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

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

[Phil Muldoon]

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

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

[Tom Tromey]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Tom> What is it that is inconsistent?

Phil> Just the naming.  With MI, because it is a machine interface, option
Phil> length is not so important.  So --no-frame-filters in the MI command
Phil> turns off a specific feature.  However, "raw" in the "bt" command
Phil> does not turn off a specific function, or is ambiguous.  I would
Phil> really like  to think of an option name that is small enough not to be
Phil> painful to type, but meaningful and specific. I could not, so I just
Phil> highlighted it in the review.

Ok, thanks.

I do think it would be useful to have an option meaning "disable value
pretty printing for this bt".  Perhaps that should be "raw" and we
should have a different name for this.  Or maybe "raw" should mean both
-- since that would truly be "raw".

Phil> Well there are two steps.  The actual filtering, this occurs when
Phil> frame filters operate on the frame iterator.  Errors can occur
Phil> here, though I suppose the scope for that is considerably narrower
Phil> than in the printing phase.  If an error occurs in this phase I think
Phil> (though the patch does not do this right now), we abandon the stack
Phil> trace with an error message of the name of the erroring filter, and
Phil> defer to GDB's inbuilt backtrace.  For both MI and CLI.  As no frames
Phil> have been printed yet, this would be fairly clear.

Filtering and printing, in most cases, have to be interleaved.
Otherwise I think there will be scaling issues.

The case where interleaving is not possible is when printing the tail
end of the stack trace: "bt -50".  Here you have to save the last N
frames somewhere before printing.

Phil> At the printing step this is a different issue.  At this point all of
Phil> the frame filters have executed. Now the Python code is printing out
Phil> the backtrace frame-by-frame with its own built-in routines according
Phil> to how each frame wrapper decorates each frame.  I think an error
Phil> with the frame wrapper as you suggested, then moving onto the next
Phil> frame is probably best here?

I tend to think just erroring out immediately is ok.
A tool like ABRT ought to send both "bt full" and "bt full raw" anyway,
to avoid these kinds of potential problems; and users can react
accordingly easily enough -- just disable the printer and repeat the
command.

Tom

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

[Phil Muldoon]

On 12/03/2012 09:34 PM, Tom Tromey wrote:
>>>>>> "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?

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

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

[Tom Tromey]

>>>>> "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

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

[Phil Muldoon]

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