Re: MI command -stack-list-locals

[Jason Molenda <jmolenda@apple.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