This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] -stack-info-frames
On Sat, Jun 18, 2005 at 08:53:32PM +1200, Nick Roberts wrote:
> I've talked myself out of implementing -stack-info-frame to give the selected
> frame because I thought that "-stack-list-frames 0 0" gave this. Now I see
> that it gives the innermost frame where execution has stopped (the current
> frame?). I'm not sure that I should have done that because if the user type a
> CLI command like "up" in the GUD buffer, I don't see how Emacs could keep
> track of the selected frame. Apple's implementation of GDB/MI presumably has
> something extra (frame-changed notification?) to do that.
Yes, the current frame.
Talk to me about this GUD buffer for a second. How does it work -
-interpreter-exec?
I think it's becoming clear that we need to have the MI output for
commands whether or not we also have the CLI output. Right now we've
got these:
(gdb)
up
&"up\n"
^done,frame={level="2",addr="0x0813f48d",func="gdb_wait_for_event",args=[],file="/big/fsf/local/src/gdb/event-loop.c",line="753"},line="753",file="/big/fsf/local/src/gdb/event-loop.c"
(gdb)
(gdb)
-interpreter-exec console up
~"#1 0xb7d621ae in poll () from /lib/tls/i686/cmov/libc.so.6\n"
^done
But wouldn't this be better?
(gdb)
-interpreter-exec console up
~"#1 0xb7d621ae in poll () from /lib/tls/i686/cmov/libc.so.6\n"
^done,frame={level="2",addr="0x0813f48d",func="gdb_wait_for_event",args=[],file="/big/fsf/local/src/gdb/event-loop.c",line="753"},line="753",file="/big/fsf/local/src/gdb/event-loop.c"
Meanwhile, we don't have this ability. So maybe we do need
-stack-info-frame, without an argument.
--
Daniel Jacobowitz
CodeSourcery, LLC