From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8542 invoked by alias); 2 Aug 2012 14:46:37 -0000 Received: (qmail 8530 invoked by uid 22791); 2 Aug 2012 14:46:34 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_EG,T_RP_MATCHES_RCVD 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, 02 Aug 2012 14:46:18 +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 q72EkEni001709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 10:46:14 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q72EkDZ3004352; Thu, 2 Aug 2012 10:46:14 -0400 Message-ID: <501A92B5.4070302@redhat.com> Date: Thu, 02 Aug 2012 14:46:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Don't attach to 'target_changed' observer in regcache References: <1343891847-16554-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1343891847-16554-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-08/txt/msg00066.txt.bz2 On 08/02/2012 08:17 AM, Yao Qi wrote: > Hi, > When I am modifying 'target_changed' observer, I don't understand > why we attach regcache_observer_target_changed to 'target_changed' > observer, and invalidates all regcache. 'target_changed' observer > is notified in valops.c:value_assign, before that, register is > modified by calling either gdbarch_value_to_register or > put_frame_register_bytes. Looks like regcache is in a good state, > why do we have to invalidate them? > > The code that invalidates all regcache was added by this patch, > > Multiplexed registers and invalidating the register cache > http://sourceware.org/ml/gdb-patches/2004-04/msg00282.html > > The author (Orjan) tried to support "changing the bank select register > changes the contents (and meaning) for a whole set of other registers." > The requirement is quite specific to Orjan's own port, so the better > solution is to attach a function which invalidates all regcache in > Orjan's backend, instead of doing it in target-independent part. Really not sure about this. There were also comments from Dan and Cagney on that thread, that point at need for this being not that uncommon. E.g. Dan wrote: > I've been meaning to do this for a long time. For instance, there is a > writeable register on PowerPC targets which has some read-only bits. > Right now, if you set it to an arbitrary value and then print it you'll > get the value GDB wrote - not the value that was actually accepted into > the register. > > Andrew convinced me that the performance cost associated with this > would be small in practice. I think you get to argue against the whole picture, not just Orjan's port, although I think we'd also need a plan to address the original issue in some other way. E.g., I can picture that gdb might not even have any knowledge of such registers (so no way to hardcode when-to-flush in the backend), as they may have been included as part of a target description, in addition to core registers. -- Pedro Alves