This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: event notification
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Jim Ingham <jingham at apple dot com>
- Cc: gdb at sourceware dot org, dmi-discuss at lists dot freestandards dot org
- Date: Sun, 16 Jul 2006 11:11:23 +1200
- Subject: Re: MI: event notification
- References: <17560.40409.61785.698765@kahikatea.snap.net.nz> <20060621013437.GA17956@nevyn.them.org> <17560.44395.508930.351917@kahikatea.snap.net.nz> <20060621023258.GA19167@nevyn.them.org> <0DEBAC0A-BF26-414A-ABE6-DFE5105A684C@apple.com>
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