MI: event notification

[Nick Roberts]

Jim Ingham writes:
 > We don't do what Nick's suggesting.  We do do something similar for  
 > shared library notifications - we emit async notifications for shared  
 > library load events from gdb so Xcode doesn't have to stop on solib  
 > events & get the shlig list.  Similarly if a shared library load  
 > causes a pended breakpoint to get loaded we tell about that as well.
 > 
 > But we don't do anything for stack changes.  Note, except in the case  
 > where you have gotten stuck in some kind of pathological recursion, I  
 > would be surprised if it's consing up the stack list for the MI that  
 > takes a significant portion of the time, so I'm not sure this example  
 > isn't a false optimization.  But anyway, we don't do that.

I thought previous discussion (Vladimir Prus) suggested that
-stack-list-argments, at least, was time consuming.  If the stack is 1000's of
frames deep, it must surely be time comsuming to compute and re-display it at
every step.  The depth can be restricted but I think you have said that the
first ones take are the hardest to compute.

In any case, we need to be scientific about it, so I propose to add a time
field to the MI output.  ISTR that Apple's MI already has this.  Are you
planning to include this (or the async notifications for shared librarys) in
the DMI specification?  I would like to avoid unnecessary duplication of
effort.


-- 
Nick                                           http://www.inet.net.nz/~nickrob