variable objects and registers
Vladimir Prus
ghost@cs.msu.su
Thu Dec 21 08:34:00 GMT 2006
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
More information about the Gdb-patches
mailing list