Re: -var-list --locals proposal

[Daniel Jacobowitz <drow@false.org>]

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".

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

> 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 :-)

-- 
Daniel Jacobowitz
CodeSourcery