Re: MI: event notification

[Jim Ingham <jingham@apple.com>]

On Jul 15, 2006, at 4:11 PM, Nick Roberts wrote:

> 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.

We have a simple backtracer that just follows the frame pointer, and  
doesn't do any of the fancy unwinding of registers, etc.  When I get  
it to print roughly the same information as the ordinary -stack-list- 
frames it's ~10 times faster than -stack-list-frames.  So I'm pretty  
sure most of the time in -stack-list-frames is doing real work  
computing the backtrace, and only a small portion is consing up the  
output.  To tell whether the stack has changed or not you have to do  
the backtrace (even if you don't report it.)  So my guess is this  
change wouldn't save very much time.

The shared-libraries one was a win because we got the UI out of the  
process of stopping & starting again on shared library hit.  For

>
> 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.

Dunno if the timing belongs in the spec, since it's more of a  
diagnostic thing.  But it is really handy to have...  The shared  
library notification is really useful and probably should go in.

Jim