From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119539 invoked by alias); 10 Aug 2016 15:49:04 -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 118564 invoked by uid 89); 10 Aug 2016 15:49:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 10 Aug 2016 15:49:02 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 930B8779; Wed, 10 Aug 2016 15:49:00 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7AFmvYm031507; Wed, 10 Aug 2016 11:48:58 -0400 Subject: Re: [PATCH v2] Fix -var-update for registers in frames 1 and up To: Don Breazeal , gdb-patches@sourceware.org, andrew.burgess@embecosm.com References: <1465854882-42527-1-git-send-email-donb@codesourcery.com> From: Pedro Alves Message-ID: <5e305a9a-5582-a2e9-240d-48845ac903d6@redhat.com> Date: Wed, 10 Aug 2016 15:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1465854882-42527-1-git-send-email-donb@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-08/txt/msg00122.txt.bz2 On 06/13/2016 10:54 PM, Don Breazeal wrote: > The fix is to change the initialization of innermost_block in > varobj_create from NULL to the global block, as returned by > block_global_block. Hmm, this sounds questionable to me. innermost_block is an output parameter, after all. parse_exp_1 already takes an input block parameter. > Then varobj_create sets varobj->root->frame for register varobjs, and > value_of_root_1 can check for the global block when determining > whether the variable is in-scope and select the frame appropriately. > > A side-effect of this change is that for register varobjs and some > global variable varobjs, the output of -var-create now includes the > thread-id field. The rationale for this is as follow: if we ask for > a particular expression in a particular frame, that implies a > particular thread. Thus including the thread-id is correct behavior, > and the test results have been updated accordingly. Sounds OK for register varobjs, but it's not as clear for global variable varobjs. I see no way to tell -var-create to create a global variable fixed varobj that is _not_ associated with a particular thread: -var-create {name | "-"} {frame-addr | "*" | "@"} expression The docs say: If an expression specified when creating a fixed variable object refers to a local variable, the variable object becomes bound to the thread and frame in which the variable object is created. When such variable object is updated, GDB makes sure that the thread/frame combination the variable object is bound to still exists, and re-evaluates the variable object in context of that thread/frame. So if the expression needed a frame, then it gets bound to the frame/thread. But if it didn't, then it won't, by my reading? I worry about whether this might break frontends. In principle, this sounds similar to watchpoints -- those also need to check whether the original expression is still in scope, for the case of watchpoints on local variables. See update_watchpoint. I'm still trying to wrap my head around all this, and I need to read the varobj code to understand how this all works. Thanks, Pedro Alves