Re: How does GDB/MI give the current frame

[Jason Molenda <jmolenda@apple.com>]

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)


(Ignore the "console-quoted"  -- we have a separate interpreter for  
console output marshalled through the MI quoting rules)

(and ignore the time= thing at the end; that's a little internal debug  
thing we use to track down performance problems more easily between gdb  
an the UI.  Our UI has a feature where it saves all MI text to a file  
for debugging; it's *invaluable* for tracking down bugs and our UI  
timestamps its own logging messages so we can tell whether the UI or  
gdb is being slow when we get reports of slowness.)


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


J