This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix -var-update for registers in frames 1 and up
- From: Andrew Burgess <andrew dot burgess at embecosm dot com>
- To: Don Breazeal <donb at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 8 Jun 2016 14:00:51 +0100
- Subject: Re: [PATCH] Fix -var-update for registers in frames 1 and up
- Authentication-results: sourceware.org; auth=none
- References: <1465335417-36881-1-git-send-email-donb at codesourcery dot 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