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: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 13 Apr 2016 19:18:44 +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
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
I have not delved into the details, but this feels in principle similar to
inline frames.
With inline frames, if you do "backtrace", you see all the inline expansions as
virtual frames. For the user, the inline frames look like normal frames. If
you do "up", gdb peels out one inline expansion. Another "up", another level.
Enough "up"s, and you're now looking at the "real" stack frame where the first
inline expansion happened.
With frame filters, a similar thing sounds like would be needed. If you
backtrace and see:
(gdb) bt
#0 0x0000000000400501 in foo () at foo.c:14
#1 0x0000000000401000 in bar () at bar.c:32
... and those were frames cooked by, or decorated by, a frame filter, then, I'd
expect that if you "frame", gdb first shows:
#0 0x0000000000400501 in foo () at foo.c:14
and then if you do "up", then "frame", gdb shows:
#1 0x0000000000401000 in bar () at bar.c:32
Does that make sense?
--
You are receiving this mail because:
You are on the CC list for the bug.