From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13071 invoked by alias); 5 Nov 2012 20:10:43 -0000 Received: (qmail 13026 invoked by uid 22791); 5 Nov 2012 20:10:36 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_EG 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; Mon, 05 Nov 2012 20:10:29 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qA5KAQDL013284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Nov 2012 15:10:26 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qA5KAPQ4029123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 Nov 2012 15:10:25 -0500 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> <87lielqcba.fsf@fleche.redhat.com> <509398D8.7060104@codesourcery.com> <87zk30ot22.fsf@fleche.redhat.com> <5097941F.8080604@codesourcery.com> Date: Mon, 05 Nov 2012 20:10:00 -0000 In-Reply-To: <5097941F.8080604@codesourcery.com> (Yao Qi's message of "Mon, 5 Nov 2012 18:25:35 +0800") Message-ID: <874nl3n74e.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/msg00092.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> I also see lval_memory on x86-64, and I am a little surprised that you Yao> see lval_register. [...] Yao> and I think it is reasonable to see 'lval_memory' instead of Yao> lval_register' here. When executing this 'set' command, the callchain Yao> looks like, Thanks for walking me through it. I agree this is the intended design. >> Second, Pedro pointed out this PR: >> http://sourceware.org/bugzilla/show_bug.cgi?id=7574 >> ... which seems apropos. It seems that the best thing is a generic >> "target changed" notification for the reasons mentioned there. Yao> 'target changed' observer and 'register changed' observer serves Yao> differently. 'target changed' observer is mostly for keeping gdb Yao> internal states, such as regcache and frames, consistent, however, Yao> register changed' observer is for external notifications. Yao> AFAICS, the reason 'target changed' observer is not replaced by Yao> memory changed' observer and 'register change' observer is that GDB Yao> doesn't know the side effect of setting a register or a piece of Yao> memory, so GDB conservatively uses 'target changed' observer. I think the implication is that nearly any change can require the front end to need to reset everything and so trying to make gdb differentiate between the various events will never work out. So, gdb might as well emit something very generic rather than =register-changed. For example, a register change can affect the variable view, the memory view (if the register is from some more-outer frame and the user is viewing the stack), the backtrace view, etc. Or, a memory change can also affect any of these, including the register view if the changed memory happens to be where a register is stored. So, in general, it seems the only safe thing for a front end is to just refresh everything on any change. What do you think? Tom