Re: [PATCH] -stack-info-frames

[Daniel Jacobowitz <drow@false.org>]

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