MI command -stack-list-locals

MI command -stack-list-locals

[Nick Roberts]

As part of the transition from annotations to GDB/MI in Emacs, I would like
to extend the MI command -stack-list-locals.

Insight appears to display watch expressions and local variables in the same
way, where the values of arrays and structures can be expanded or contracted
with a mouse click. Perhaps it creates variable objects for both. GDB/MI,
however, either prints just the names of the locals, or their names and all
of their values i.e. entire structures and arrays. This can be a nuisance
with large arrays or structures and I would like to extend -stack-list-locals
to do the following:

1) Display the name and value for simple data types.
2) Display the name and type for complex data types.

e.g with the local variables:

  int i, m[10];
  struct {
    int j;
    int k;
  } values;

the output for "-stack-list-locals 2", say, would be:

^done,locals=[{name="i",value="5"},
              {name="m",type="int [10]"}
              {name="values",type="struct {...}"}]


Then the user could examine an array or structure in more detail by creating a
variable object for it (through a mouse click on its name). Currently, I use
the speedbar for watch expressions and Emacs only allows there to be one. This
means that watch expressions and (expanded/contracted) local variables must
share it.

As this modification to -stack-list-locals won't be easy for me to implement,
I am looking for some reassurance that such a change, subject to the usual
requirements, would be accepted.


    Nick                                         http://www.nick.uklinux.net

Re: MI command -stack-list-locals

[Jason Molenda]

Hi Nick, sorry for the late reply.

On Nov 6, 2003, at 2:04 PM, Nick Roberts wrote:

>  This can be a nuisance
> with large arrays or structures and I would like to extend  
> -stack-list-locals
> to do the following:
>
> 1) Display the name and value for simple data types.
> 2) Display the name and type for complex data types.
>
> e.g with the local variables:
>
>   int i, m[10];
>   struct {
>     int j;
>     int k;
>   } values;
>
> the output for "-stack-list-locals 2", say, would be:
>
> ^done,locals=[{name="i",value="5"},
>               {name="m",type="int [10]"}
>               {name="values",type="struct {...}"}]


We've been handling many of the same issues here at Apple for the past  
few years.  Jim's the real expert in regard to our varobj  
modifications, but here's a quick example that might be helpful for  
your problem.

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.  On the above example, we output

-stack-list-locals 2

^done,locals=[

varobj={exp="i",value="5",name="var1",numchild="0",type="int",typecode=" 
INT",dynamic_type="",in_scope="true",block_start_addr="0x00001dd0",block 
_end_addr="0x00001e04"},

varobj={exp="m",value="[-1]",name="var2",numchild="10",type="int  
[10]",typecode="ARRAY",dynamic_type="",in_scope="true",block_start_addr= 
"0x00001dd0",block_end_addr="0x00001e04"},

varobj={exp="values",value="{...}",name="var3",numchild="2",type="struct 
   
{...}",typecode="STRUCT",dynamic_type="",in_scope="true",block_start_add 
r="0x00001dd0",block_end_addr="0x00001e04"}

],time={wallclock="0.00179",user="0.01000",system="0.00000",start="10687 
68005.990265",end="1068768005.992059"}

I inserted some newlines to make it more readable; of course it's all  
on one line in the real output.

The type of the variable is in the TYPE field; the TYPECODE field is a  
general description for the IDE -- it is the string representation of  
the TYPE_CODE of the varobj (e.g. PTR, ARRAY, STRUCT, ENUM, INT, FLT,  
etc.) which gives the UI an easy way to tell how it should be  
represented to the user.

IN_SCOPE works correctly with our gdb.

DYNAMIC_TYPE is to represent when a varobj is pointer to a C++ class  
that may point to classes higher up the inheritance tree so the UI can  
keep its display up to date as the type changes.

Oh, and the TIME thing at the end is just a little performance monitor  
deal we use internally when we're hunting for slow-downs between the UI  
and gdb; that doesn't have anything to do with the varobj's.



Jason

Re: MI command -stack-list-locals

[Nick Roberts]

 > 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?



 >                     On the above example, we output
 > 
 > -stack-list-locals 2
 > 
 > ^done,locals=[
 > 
 > varobj={exp="i",value="5",name="var1",numchild="0",type="int",typecode=" 
 > INT",dynamic_type="",in_scope="true",block_start_addr="0x00001dd0",block 
 > _end_addr="0x00001e04"},
 > ...

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?

Thanks for the info.

Nick

Re: MI command -stack-list-locals

[Alain Magloire]

> 
> 
>  > 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.  For example, some variables are "volatile" or
can be map to some register or memory.  So you do not want to inadvertly
query them when doing:

-var-update *
-var-update var1

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.

For adding the type in the output, it is a good idea.  So I will not
have to issue a second "whatis" and "ptype", cuts down on the traffic.

My 0.0002 cents canadian.

Re: MI command -stack-list-locals

[Jason Molenda]

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