This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: event notification

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]