From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41202 invoked by alias); 8 Jun 2016 13:01:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 41172 invoked by uid 89); 8 Jun 2016 13:01:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 08 Jun 2016 13:01:10 +0000 Received: by mail-wm0-f50.google.com with SMTP id k184so16576590wme.1 for ; Wed, 08 Jun 2016 06:01:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VonoaYdUtABDk8lunNvLbwBN5nEFpRGXLxqA45naDzM=; b=mHyWiNZnLypRU6QS0QUxz5ay6AmjkhiT2A0o/rpKs+3/5pngNHdHb+2QNsbEoN7IT5 KRaMqLVac0bhGHfDEoxpYSZry6MBfvydgSL2Oj25RemtZhQW58URr+9xsqC7vzeD1Eb9 ufOhnyH3TSCEwWiv/p/myyOD4RlmhQh9CGwgG0Zjssoo50kOecQqeUANuaS6aF1TXCZ6 uk/s3lXgolJRoXM3HlaxW/icc2ruWKn9xMk1SwyzoqTMfMHNaJrkoq/raug+vViT3gdG ksy4zY100uc6gGRy4/Zr8vfOLy4MQ5ABGL6pudbbFnUsETyeeYTjqFxdnf22ovqIJeft s1aw== X-Gm-Message-State: ALyK8tLALNtSVGGc8hZjQ4fM9U8ZmMG5XguGAUTLKjyspZox6Yn6Jy7BvcQ+vzZCBlZ9RQ== X-Received: by 10.194.163.166 with SMTP id yj6mr4532484wjb.116.1465390867372; Wed, 08 Jun 2016 06:01:07 -0700 (PDT) Received: from localhost (cust64-dsl91-135-5.idnet.net. [91.135.5.64]) by smtp.gmail.com with ESMTPSA id s1sm1370070wjf.43.2016.06.08.06.01.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jun 2016 06:01:06 -0700 (PDT) Date: Wed, 08 Jun 2016 13:01:00 -0000 From: Andrew Burgess To: Don Breazeal Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix -var-update for registers in frames 1 and up Message-ID: <20160608130051.GC26734@embecosm.com> References: <1465335417-36881-1-git-send-email-donb@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1465335417-36881-1-git-send-email-donb@codesourcery.com> X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.6.1 (2016-04-27) X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00158.txt.bz2 * Don Breazeal [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. > > > 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