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: Wed, 05 Dec 2012 10:36:46 -0700
- Subject: Re: [patch][python] 0 of 5 - Frame filters and Wrappers
- References: <50B8C313.2070404@redhat.com> <87k3syvmzd.fsf@fleche.redhat.com> <50BF3E9D.4080403@redhat.com>
>>>>> "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