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

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Don Breazeal <donb@codesourcery.com> [2016-06-07 14:36:57 -0700]:

> This patch fixes a problem with using the MI -var-update command
> to access the values of registers in frames other than the current
> frame.  The patch includes a test that demonstrates the problem:
> 
> * run so there are several frames on the stack
> * create a varobj for $pc in each frame, #'s 1 and above
> * step one instruction, to modify the value of $pc
> * call -var-update for each of the previously created varobjs
>   to verify that they are not reported as having changed.
> 
> Without the patch, the -var-update command reported that $pc for all
> frames 1 and above had changed to the value of $pc in frame 0.
> 
> The -var-create command takes a '--frame' argument and uses that
> to select the frame for retrieving the register value.  But -var-update
> has no such argument, and previously didn't do anything to select the
> frame, so for frames other than frame 0 it returned the value of the
> register for frame 0, instead of reporting the value as unchanged.

This shouldn't need special handling for register varobj values, if I
create a varobj watching value 'foo' in frame 1, but have a local
'foo' in frame 0, a change in frame 0 'foo' will not trigger a change
for frame 1's 'foo' varobj.

The magic is actually in varobj.c:check_scope, which makes use of the
varobj->root->frame to select the right frame based on the type of the
varobj, this is setup at varobj creation time.

The problem, is that for register expressions the varobj->root->frame
is not set correctly.  This frame tracking is done using the global
'innermost_block' which is set in the various parser files (for
example c-exp.y), however, this is not set for register expressions.
I think that we probably should be doing this in
write_dollar_variable.

> 
> The solution implemented here is for varobj.c:varobj_update to
> handle register varobjs by calling select_frame using the frame
> associated with the varobj's value.  If the frame isn't found
> varobj_update throws an error.
>

<snip>

> 
> diff --git a/gdb/varobj.c b/gdb/varobj.c
> index 6f56cba..e8f2e04 100644
> --- a/gdb/varobj.c
> +++ b/gdb/varobj.c
> @@ -1610,6 +1610,19 @@ varobj_update (struct varobj **varp, int is_explicit)
>        r.varobj = *varp;
>        r.status = VAROBJ_IN_SCOPE;
>  
> +      /* If updating a register varobj, select the correct frame.  */
> +      if ((*varp)->root->exp != NULL
> +	  && (*varp)->root->exp->elts[0].opcode == OP_REGISTER)
> +	{
> +	  struct frame_info *fi;
> +
> +	  fi = frame_find_by_id (VALUE_FRAME_ID ((*varp)->value));
> +	  if (fi != NULL)
> +	    select_frame (fi);
> +	  else
> +	    error (_("Failed to find the frame for the specified register"));
> +	}
> +
>        /* Update the root variable.  value_of_root can return NULL
>  	 if the variable is no longer around, i.e. we stepped out of
>  	 the frame in which a local existed.  We are letting the 

This will break things if I create a floating varobj tracking (say)
$pc.  In that case I _do_ expect to pick up the $pc in the outermost
frame. Something like:

   -var-create --thread 1 --frame 1 - @ $pc
   next
   -var-update 1 *

Should show my variable as having changed I think.

Thanks,
Andrew