This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug python/18567] Frame filters apply to 'backtrace' but not 'frame' command
- From: "tromey at sourceware dot org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 14 Apr 2016 17:59:39 +0000
- Subject: [Bug python/18567] Frame filters apply to 'backtrace' but not 'frame' command
- Auto-submitted: auto-generated
- References: <bug-18567-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18567
--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Phil Muldoon from comment #2)
> I'm not sure how a frame filter can apply to a single line of output?
I think the simplest way here is to start the frame iteration process
at the selected frame (not the newest frame); and then just request a
single frame from the iterator and print that.
> If one frame is only ever
> printed (regardless, say, if the iterator had more than one), then a frame
> filter is not needed: there's nothing to filter. Perhaps we could apply a
> single frame decorator?
Yeah, just request one from the iteration process.
A frame filter may choose to consume multiple frames in order to do its
filtering. That's ok though.
The concrete case for SpiderMonkey is that the JIT unwinder has found
some frames -- but we don't add any display information from the unwinder
(you really just can't and anyway if you could it is too hard anyway);
so all the user-useful information is delegated to the frame filter.
In this case the frame filter is always 1:1 with underlying frames,
though of course there's no reason to restrict things in this way.
> However, that would be a pain as previously written frame filters that would
> apply to backtraces would have to adapt to just returning one frame for
> these and other commands.
Well-written frame filters are supposed to be lazy already.
And, even if they aren't, it doesn't matter, since gdb can always
choose exactly what it prints.
One way to look at this is that "bt" is paginated and nothing breaks
if we don't print every single frame in the stack every time.
--
You are receiving this mail because:
You are on the CC list for the bug.