Re: variable objects and registers

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

On Thursday 21 December 2006 10:52, Nick Roberts wrote:
>  > > gdb_block_vars only gets called if gdb_get_blocks finds a new block which
>  > > then finds any variabes local to it.  That way new variable objects can be
>  > > added (and old ones deleted if a block has disappeared) while keeping
>  > > the variable objects which are still in scope.  I think we should implement
>  > > these functions in MI (perhaps Apple already have).
>  > 
>  > Again, I think we need more automated approach. Frontend should have a
>  > single command  that:
>  > 
>  > 	1. Reports which local variables are really dead now
>  > 	2. Creates and reports variable object for new locals 
>  > 	3. Reports which varobjs are out of scope
> 
> We don't seem to be finding much agreement, except that what I have described
> does 2 and 3, and I don't really understand the difference between 1 and 3
> When would a variable belong to just one of those two groups?

If you've left a function, then all variables in that function are really dead. If you
have a variable in most-nested scope in a function (say inside loop), that variable
can go in scope and go out of scope many times as you step though the function.
When you leave a function, the frontend might want to completely remove its
data structures. When leaving local scope, it might want to just show the relevant
GUI item is "out of scope" -- gray perhaps.

>  > For example:
>  > 
>  >     -var-update --locals
>  >     ^done,varobjs=[{name="v1",in_scope="false"....}{"name="v2",in_scope="true"....}]
>  >                created=[{name="v3"....],
>  >                gone-forever=[{name="v0"...}]
>  > 
>  > 
>  > Apple creates varobjs for all variables in all blocks in a function, and use
>  > "in_scope" to track their scope. That might be good approach too. IIRC,
>  > you've posted a patch to consider block boundaries when computing
>  > "in_scope"? That's exactly what's needed for this approach to work.
> 
> Yes, I'm fairly sure that's what the above functions from Insight do.  That
> wouldn't be a coincidence either because ChangeLog records show that Jim Ingham
> worked on Insight while at Cygnus.

The first point I'm making here is that MI is not in-process interface, so we need to minimize
the amount of commands. I believe that to update local variables, frontend should emit *one*
command, that would provide all the necessary information -- including new/deleted varobjs,
in/out scope, and new values.

- Volodya