This is the mail archive of the
mailing list for the GDB project.
Re: MI: event notification
- From: Jim Ingham <jingham at apple dot com>
- To: Nick Roberts <nickrob at snap dot net dot nz>
- Cc: gdb at sourceware dot org, dmi-discuss at lists dot freestandards dot org
- Date: Mon, 17 Jul 2006 14:11:03 -0700
- Subject: Re: MI: event notification
- References: <firstname.lastname@example.org> <20060621013437.GA17956@nevyn.them.org> <email@example.com> <20060621023258.GA19167@nevyn.them.org> <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com> <firstname.lastname@example.org>
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
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
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
field to the MI output. ISTR that Apple's MI already has this. Are
planning to include this (or the async notifications for shared
the DMI specification? I would like to avoid unnecessary
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.