Re: How does GDB/MI give the current frame

Alain Magloire
2004-07-16T14:04:14Z

>
>
> On Jul 15, 2004, at 12:45 PM, Nick Roberts wrote:
>
> >> That's almost the whole idea. The -interpreter-exec command provides
> >> two mechanism to the GUI/client:
> >>
> >> - the ability to access GDB's `console' vis:
> >> -> -interpreter cli "up"
> >> <- ~"info on new frame..."
> >> <- done
> >>
> >> - the ability to notify the GUI of console sideeffects vis:
> >> <- *select-frame,<frame-info>...
> >
> > That sounds like a third interface. This is an elegant approach but
> > assumes
> > that someone will implement the notification for every CLI command
> > that has
> > side effects. This seems unlikely in the current circumstances
>
>
> For what it's worth, at Apple we've done what Andrew is proposing. Our
> method spits out a "MI_HOOK_RESULT" notification on the ^done result
> whenever the console command entered by the user has changed the state
> in an important way. e.g.
>
> (gdb)
> -interpreter-exec console-quoted up
> ~"#2 0x000321f4 in gdb_main (args=0xbffff620) at
> ../../gdb/src/gdb/main.c:851\n"
> ~"851\t catch_errors (captured_main, args, \"\", RETURN_MASK_ALL);\n"
> ^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="2"],time=
> {wallclock="0.00620",user="0.00323",system="0.00283",start="1089921236.3
> 59009",end="1089921236.365212"}
> (gdb)
>

But what Andrew is proposing is to use the async-output already part of MI to notify
the UI of changes.
What you are showing here is this new MI_HOOK_RESULT, unless the output is missing lines ?

>
>
> FWIW, here's the list of notification hooks we currently generate:
> breakpoint_create, breakpoint_modify, breakpoint_delete, stack_changed,
> frame_changed, thread_changed.
>

Cool !