Re: -var-list --locals proposal

[Vladimir Prus <ghost at cs dot msu dot su>]

Daniel Jacobowitz wrote:

> On Fri, Jan 05, 2007 at 11:03:59PM +0300, Vladimir Prus wrote:
>> At the moment, to reliably show all locals, the frontend is forced to
>> emit -stack-list-locals on each step. To handle the case where a new
>> variable is in nested scope and has the same name as a variable in outer
>> scope, the frontend should compute addresses of all variables on each
>> step, and notice when they change. This is rather nasty.
>> 
>> I propose to introduce a new command:
>> 
>> -var-list --locals <frame>
>> 
>> This command returns variable objects corresponding to every local
>> variable that is "live" at the current position in the program. If at all
>> possible, the command tries to return previously returned variable
>> object.
>> 
>> So, on each step, the frontend emits -var-list --locals and:
>> 
>> 1. For all variable objects it never seen, create new GUI
>> elements.
>> 2. For all variable objects that were reported previously,
>> but are no longer reported, delete GUI elements.
> 
> I think most of the complexity in this will come from reusing varobjs.
> Couldn't we do this with -var-update?  The meaning of in_scope="false"
> is a bit unclear today, since we use it for anything whose value we
> can't find, and in optimized code a variable can go in and out of
> scope.  So using that might not be a good idea.  We could add another
> marker, though, such as frame_exited="true" to indicate that a varobj's
> associated frame has returned (or otherwise disappeared from the
> stack).  A varobj would never transition from frame_exited="true" to
> frame_exited="false".

I think it would be good to reuse varobj accross the frames. So,
if you're in some function and look at its locals and then enter
another function and try to look at parents variables you get
the same varobjs. I don't think that creation of varobj is 
so expensive in gdb itself -- but for frontend it's more
convenient to always have the same varobj associated with 
a variable.



>> The question is what exactly can be considered "live" variables by
>> -var-list. I think that to avoid creating and destroying variable
>> objects as we step though inner blocks, -var-list should construct
>> varobjs for all variables in all blocks of a function.
> 
> We could call this --all-locals; I think that "for the given frame"
> is implied.

--all-locals is fine with me.

>> Transition between those states can be reported via -var-update. The
>> differences between (1) and (3) is already reported via "in_scope"
>> attribute. I'm not sure if we need to expose the difference between (2)
>> and (3), and if so, if it's better to introduce another attribute --
>> "hidden" with values "true" and "false", or new attribute "visibility",
>> with values of:
>> 
>> "yes"
>> "hidden"
>> "out_of_scope"
> 
> C and C++ both call this "hidden"; GCC calls it shadowing (-Wshadow).
> You're right that this is just a detail.  I'll try not to make my
> frequent mistake of focusing too much on the hardest and least useful
> case :-)

:-)

- Volodya