Re: MI: event notification

Nick Roberts
2006-07-15T23:12:43Z

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.