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

[Phil Muldoon <pmuldoon@redhat.com>]

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