Re: per-thread variable objects

[Vladimir Prus <vladimir@codesourcery.com>]

On Monday 24 March 2008 23:59:20 Nick Roberts wrote:
>  > I've checked it the following revision of Nick's previous
>  > patch (http://permalink.gmane.org/gmane.comp.gdb.devel/22707) that
>  > makes variable object remember the thread they belong to.
>  > I've tested this manually, proper thread and docs will be following
>  > shortly.
>  > 
>  > Nick,
>  > the changes I've made are as follows:
>  > 
>  > 	- I use the valid_block instead of special -2 value
>  > 	to check if a varobj is global.
>  > 	- I did not use -1 value to indicate the thread is gone. Presently,
>  > 	we don't specifically mark variables object whose frame is gone,
>  > 	and I don't see why we should be do differently for threads.
>  > 
>  > If something seems wrong, please say.
> 
> It would be nice to reach an agreement before the changes are commmitted.

You are right; I apologise for rushing to cross an item from my todo list.

>  > Index: gdb/ChangeLog
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/ChangeLog,v
>  > retrieving revision 1.9247
>  > diff -u -p -r1.9247 ChangeLog
>  > --- gdb/ChangeLog	23 Mar 2008 17:29:32 -0000	1.9247
>  > +++ gdb/ChangeLog	24 Mar 2008 17:31:09 -0000
>  > @@ -1,3 +1,15 @@
>  >...
> 
> I think ChangeLog entries shouldn't be presented as diffs.

Does that cause any practical issue to anybody?

>  >...
>  > +/* If frame associated with VAR can be found, switch
>  > +   to it and return 1.  Otherwise, return 0.  */
> 
> It's not enough for a frame to be found, the pc also has to have an address
> value within the valid block.  This is one reason why, for such small
> functions, I would rather the code spoke for itself.

To be honest, the checking for block boundaries cries for comments too.
It's not really appparent why we check for it, and importantly -- should
variables not in the current block be reported as "out of scope", or 
reported in some other way.

- Volodya