Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Don Breazeal <donb@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix -var-update for registers in frames 1 and up
Date: Wed, 08 Jun 2016 13:09:00 -0000	[thread overview]
Message-ID: <20160608130856.GD26734@embecosm.com> (raw)
In-Reply-To: <20160608130051.GC26734@embecosm.com>

* Andrew Burgess <andrew.burgess@embecosm.com> [2016-06-08 14:00:51 +0100]:

> * 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.

Something like the following (untested):

diff --git a/gdb/parse.c b/gdb/parse.c
index 2b00708..224c022 100644
--- a/gdb/parse.c
+++ b/gdb/parse.c
@@ -705,6 +705,10 @@ handle_register:
   str.ptr++;
   write_exp_string (ps, str);
   write_exp_elt_opcode (ps, OP_REGISTER);
+  if (innermost_block == NULL
+      || contained_in (expression_context_block,
+		       innermost_block))
+    innermost_block = expression_context_block;
   return;
 }

Thanks,
Andrew


  reply	other threads:[~2016-06-08 13:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-07 21:37 Don Breazeal
2016-06-08 13:01 ` Andrew Burgess
2016-06-08 13:09   ` Andrew Burgess [this message]
2016-06-09  0:48     ` Don Breazeal
2016-06-09 18:23       ` Don Breazeal
     [not found]         ` <20160610103220.GJ26734@embecosm.com>
2016-06-10 21:25           ` Don Breazeal
2016-06-13  9:05             ` Andrew Burgess
2016-06-13 21:54               ` [PATCH v2] " Don Breazeal
2016-06-20 15:32                 ` [PING] " Don Breazeal
2016-07-11 14:48                   ` Don Breazeal
2016-07-20 21:07                     ` Don Breazeal
2016-07-21 16:59                       ` Don Breazeal
2016-07-29 16:13                         ` [PING^4] " Don Breazeal
2016-08-05 18:22                           ` [PING] " Don Breazeal
2016-08-10 15:49                 ` Pedro Alves
2016-10-04 20:56                   ` [PATCH v3] PR mi/20395 - " Don Breazeal
2016-10-05 14:18                     ` Pedro Alves
2016-10-07  0:05                     ` Andrew Burgess
2016-10-14 16:59                       ` Don Breazeal
2016-10-26 18:04                         ` [PING] " Don Breazeal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160608130856.GD26734@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=donb@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox