This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug python/18567] Frame filters apply to 'backtrace' but not 'frame' command


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]