From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47634 invoked by alias); 9 Jun 2016 00:48:21 -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 44696 invoked by uid 89); 9 Jun 2016 00:48:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2974, forthcoming X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 09 Jun 2016 00:48:08 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1bAo8j-0004KX-1j from Don_Breazeal@mentor.com ; Wed, 08 Jun 2016 17:48:05 -0700 Received: from [172.30.0.102] (147.34.91.1) by SVR-ORW-FEM-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 8 Jun 2016 17:48:04 -0700 Subject: Re: [PATCH] Fix -var-update for registers in frames 1 and up To: Andrew Burgess , "Breazeal, Don" References: <1465335417-36881-1-git-send-email-donb@codesourcery.com> <20160608130051.GC26734@embecosm.com> <20160608130856.GD26734@embecosm.com> CC: "gdb-patches@sourceware.org" From: Don Breazeal Message-ID: <5758BCC0.2060700@codesourcery.com> Date: Thu, 09 Jun 2016 00:48:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160608130856.GD26734@embecosm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00164.txt.bz2 On 6/8/2016 6:08 AM, Andrew Burgess wrote: > * Andrew Burgess [2016-06-08 14:00:51 +0100]: > >> * 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. Andrew, Thanks for explaining. I had followed innermost_block quite a bit in my debugging, but somehow convinced myself that wasn't the solution. > > 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; > } Your solution works for both the fixed a floating varobj cases. I've extended my new test to cover the floating case. Unfortunately in the full test suite I've run into some unexpected side-effects that need further investigation. Hopefully an updated patch will be forthcoming soon. --Don