This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI command -stack-list-locals
- From: Jason Molenda <jmolenda at apple dot com>
- To: Alain Magloire <alain at qnx dot com>
- Cc: nick at nick dot uklinux dot net (Nick Roberts), gdb at sources dot redhat dot com
- Date: Mon, 17 Nov 2003 13:11:21 -0800
- Subject: Re: MI command -stack-list-locals
- References: <200311172039.PAA17856@smtp.ott.qnx.com>
On Nov 14, 2003, at 3:10 PM, Nick Roberts wrote:
We've added a "2" version of -stack-list-locals which prints out a
lot
more information, as well as automatically creates varobj's for all
of
the local variables.
Do these variable objects get deleted and replaced with a new set
every
time the current frame changes? Does that not slow down the user
interface?
For us, it will be slow.
Yeah, for a native system we can get at the inferior's memory space
quickly and easily. The timing overhead to create a whole mess of
varobj's is amazingly small - must be the incredible power of the G5
processor or something. :-) :-) No, seriously though, every time we've
done profiling this stuff is pure noise. I just tried debugging a
smallish ObjC program; the entire series of MI commands to get the
arguments and locals for a function with two arguments and no locals
took 0.01 seconds wallclock. For a function with 11 locals/arguments,
it took 0.02 seconds wallclock.
You figure that after a stop you want to get give the user control in,
say, 0.2-0.3 seconds to get a reasonable feel (I'm just throwing out
numbers). Given that budget of time, 0.01-0.02 seconds for varobj's is
not important.
On Nov 14, 2003, at 3:10 PM, Nick Roberts wrote:
I suspect that I could use this approach for Emacs and I certainly
don't want to try do things that others have already done. At some
stage, will Apple put these changes into the RedHat CVS repository for
FSF gdb?
Apple has a copyright assignment to the FSF on file for all our gdb
work--there should be no issues with using our changes, and we're happy
to share. Our source base is (ahem) a bit diverged from the FSF
sources and we haven't completed a merge since January to boot, so
contributing much back to the FSF in the short term is not likely to
happen. It's something all of us, up through our managers, wants to
happen, but I honestly don't expect a lot of time to be spent on that
in the immediate future.
On Nov 17, 2003, at 12:39 PM, Alain Magloire wrote:
The Eclipse/CDT/MI use the fact that -stack-list-locals is not
creating
varobj(lightweight) to allow users to pick and choose which variable
to monitor.
This can be an issue when debugging a board, where you want to be less
intrusive
or when having a very high number of variables in a stackframe.
Yeah, for an embedded environment you'll have a different set of
tradeoffs you're working with. We've been shipping a UI that works on
top of MI for a few years now, and we've hit (and solved) a number of
problems along the way. I expect that other people implementing a
debugger UI via MI will encounter many of the same issues and it'd be
nice if we can share the experiences and solutions we came up with here
at Apple...
Jason