This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: -var-list --locals proposal
- From: Daniel Jacobowitz <drow at false dot org>
- To: Vladimir Prus <ghost at cs dot msu dot su>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 9 Jan 2007 22:38:41 -0500
- Subject: Re: -var-list --locals proposal
- References: <200701052303.59465.ghost@cs.msu.su>
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