This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] -stack-info-frames
> 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