From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9714 invoked by alias); 9 Jun 2016 18:23:28 -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 9701 invoked by uid 89); 9 Jun 2016 18:23:27 -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= 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 18:23:17 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1bB4br-0005d6-4e from Don_Breazeal@mentor.com ; Thu, 09 Jun 2016 11:23:15 -0700 Received: from [172.30.1.248] (147.34.91.1) by SVR-ORW-FEM-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 9 Jun 2016 11:23:14 -0700 Subject: Re: [PATCH] Fix -var-update for registers in frames 1 and up To: Andrew Burgess References: <1465335417-36881-1-git-send-email-donb@codesourcery.com> <20160608130051.GC26734@embecosm.com> <20160608130856.GD26734@embecosm.com> <5758BCC0.2060700@codesourcery.com> CC: "gdb-patches@sourceware.org" From: Don Breazeal Message-ID: <5759B40D.4010400@codesourcery.com> Date: Thu, 09 Jun 2016 18:23: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: <5758BCC0.2060700@codesourcery.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00187.txt.bz2 On 6/8/2016 5:48 PM, Breazeal, Don wrote: > 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. I haven't gone through all the failures, but I have found the cause of one of the side-effects of this change. In the CLI, the 'display' command depends on parsing a register expression to *not* set innermost_block. If the expression has a block, it has to be in-scope or display will skip it rather than evaluating the expression. See printcmd.c:do_one_display, the handling of d->block. It basically does: d->exp = parse_expression (d->exp_string); d->block = innermost_block; ---snip--- if (d->block) { if (d->pspace == current_program_space) within_current_scope = contained_in (get_selected_block (0), d->block); ---snip--- } else within_current_scope = 1; if (!within_current_scope) return; It seems like we will need a special case someplace. In do_one_display we could NULL out d->block for register expressions, or in varobj_update we could expand on the original patch to properly handle floating varobjs. Perhaps since the problem under consideration is only in MI, making the MI-specific change in varobj_update would minimize side-effects in the CLI. WDYT? I will continue investigating the failures to see if there is anything else there. thanks --Don