Re: [PATCH v2] Fix -var-update for registers in frames 1 and up

[Pedro Alves <palves at redhat dot com>]

On 06/13/2016 10:54 PM, Don Breazeal wrote:

> The fix is to change the initialization of innermost_block in 
> varobj_create from NULL to the global block, as returned by 
> block_global_block.

Hmm, this sounds questionable to me.  innermost_block is an output
parameter, after all.  parse_exp_1 already takes an input block 
parameter.

> Then varobj_create sets varobj->root->frame for register varobjs, and
> value_of_root_1 can check for the global block when determining
> whether the variable is in-scope and select the frame appropriately.
> 
> A side-effect of this change is that for register varobjs and some 
> global variable varobjs, the output of -var-create now includes the 
> thread-id field.  The rationale for this is as follow: if we ask for
> a particular expression in a particular frame, that implies a
> particular thread.  Thus including the thread-id is correct behavior,
> and the test results have been updated accordingly.

Sounds OK for register varobjs, but it's not as clear for global
variable varobjs.

I see no way to tell -var-create to create a global variable fixed
varobj that is _not_ associated with a particular thread:

 -var-create {name | "-"} {frame-addr | "*" | "@"} expression

The docs say:

 If an expression specified when creating a fixed variable object
 refers to a local variable, the variable object becomes bound to
 the thread and frame in which the variable object is created. When such 
 variable object is updated, GDB makes sure that the thread/frame combination
 the variable object is bound to still exists, and re-evaluates the variable
 object in context of that thread/frame. 

So if the expression needed a frame, then it gets bound to
the frame/thread.  But if it didn't, then it won't, by my reading?

I worry about whether this might break frontends.

In principle, this sounds similar to watchpoints -- those also
need to check whether the original expression is still in scope,
for the case of watchpoints on local variables.
See update_watchpoint.

I'm still trying to wrap my head around all this, and I need to
read the varobj code to understand how this all works.

Thanks,
Pedro Alves