Re: [PATCH] -stack-info-frames

[Nick Roberts <nickrob at snap dot net dot nz>]

 > Talk to me about this GUD buffer for a second.  How does it work -
 > -interpreter-exec?

Currently I input CLI commands directly but I know that the plan is to
remove this capability and just leave "-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) 

This is what used to happen (I get this with GNU gdb 5.2.1-2mdk, for example)
But now with GDB in CVS, I get the same output as with
"-interpreter-exec console up" (apart from "up\n" in the log stream) i.e.

up
&"up\n"
~"#1  0x08048641 in main (argc=1, argv=0xbffff794) at myprog.c:81\n"
~"81\t    myprint (i,a[i] /* hello */);\n"
^done

I don't know why you don't also get this.

 > (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"

Yes.  The same is true for the commands that control execution:

(gdb) 
-exec-next 
^running
(gdb) 
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484dd",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="50"}
(gdb) 

but

(gdb) 
-interpreter-exec console next
~"50\t  int n1=7, n2=8, n3=9;\n"
^done
(gdb) 

doesn't give the frontend any information.

Before I looked at the code, I presumed that GDB detected when execution had
stopped and the printed out "*stopped" (in which case this would happen also
with CLI commands). Looking at it, I see it is printed in
mi_execute_async_cli_command so that it appears as command output rather than
event notification

 > Meanwhile, we don't have this ability.  So maybe we do need
 > -stack-info-frame, without an argument.

Yes, unless Apple's proposed merge will provide the necessary information.

Nick