From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18764 invoked by alias); 1 Nov 2012 20:48:52 -0000 Received: (qmail 18755 invoked by uid 22791); 1 Nov 2012 20:48:51 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Nov 2012 20:48:44 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qA1Kmgra012389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Nov 2012 16:48:43 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qA1KmfPZ019926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 16:48:41 -0400 From: Tom Tromey To: Yao Qi Cc: Subject: Re: [RFC] MI notification on register changes References: <1350977008-28632-1-git-send-email-yao@codesourcery.com> Date: Thu, 01 Nov 2012 20:48:00 -0000 In-Reply-To: <1350977008-28632-1-git-send-email-yao@codesourcery.com> (Yao Qi's message of "Tue, 23 Oct 2012 15:23:28 +0800") Message-ID: <87lielqcba.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2012-11/txt/msg00027.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> User can type command in console 'set $reg = foo' to modify register. Yao> The modification may not really happen in registers, because register Yao> is already saved in frame, and modification really goes to memory (frame). Yao> The new MI notification this patch adds is about 'register change' from Yao> user's point of view, instead of from machine's point of view. Yao> Usually, MI frontend has a 'register view' to show the contents of Yao> registers. When users modify registers on a certain frame, this Yao> notification is useful to tell MI frontend to refresh its 'register Yao> view'. This all seems reasonable to me. Yao> This patch also extends the usage of field 'regnum' of 'struct value'. Yao> Originally, this field is used to store the register number if content Yao> is from register. With this patch, this field also store the register Yao> number if it "presents" a register. For example, on non-innermost Yao> frame, the value "reg" may be from memory instead of register. Yao> set $reg = foo The register may be stored in memory, but it this case really ever represented as lval_memory in gdb? I thought the reason for value::frame_id was to represent the notion of "register in a specific frame", and that all registers are represented as lval_register. Yao> +proc test_register_change { } { with_test_prefix "simple" { For new tests I would prefer correct indentation. That is, with_test_prefix on its own line. I think the existing tests are written in this funny way to avoid a massive reindentation, but that isn't a factor here. Yao> +++ b/gdb/valops.c Yao> @@ -1217,6 +1217,7 @@ value_assign (struct value *toval, struct value *fromval) Yao> + /* Figure out which frame this is in currently. */ Yao> + frame = frame_find_by_id (VALUE_FRAME_ID (toval)); Yao> + I find it pretty hard to convince myself that moving this out of the switch can't cause some obscure problem. How about hoisting the declaration of frame, initializing it to NULL, and then changing this: Yao> + if (VALUE_REGNUM (toval) >= 0) Yao> + observer_notify_register_changed (VALUE_REGNUM (toval), frame, Yao> + inferior_ptid, Yao> + value_contents (val)); ... to read 'if (frame != NULL)'? Tom