From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8401 invoked by alias); 2 Aug 2012 15:40:19 -0000 Received: (qmail 8389 invoked by uid 22791); 2 Aug 2012 15:40:18 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_EG X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Aug 2012 15:40:05 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SwxVM-0004hw-K6 from Yao_Qi@mentor.com ; Thu, 02 Aug 2012 08:40:04 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 08:40:04 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.1.289.1; Thu, 2 Aug 2012 08:40:03 -0700 From: Yao Qi To: CC: Pedro Alves Subject: Re: [PATCH] Don't attach to 'target_changed' observer in regcache Date: Thu, 02 Aug 2012 15:40:00 -0000 Message-ID: <9087332.baeLaisSVj@qiyao.dyndns.org> User-Agent: KMail/4.8.3 (Linux/3.3.7-1.fc16.i686; KDE/4.8.3; i686; ; ) In-Reply-To: <501A92B5.4070302@redhat.com> References: <1343891847-16554-1-git-send-email-yao@codesourcery.com> <501A92B5.4070302@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-IsSubscribed: yes 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/msg00069.txt.bz2 On Thursday, August 02, 2012 03:46:13 PM Pedro Alves wrote: > 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. >=20 > 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. > >=20 > > Andrew convinced me that the performance cost associated with this > > would be small in practice. >=20 I red Dan's comment, but I thought it is uncommon :) > 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. It is a good idea to extend target description for the attributes of each=20 register, for example, a certain bit of a register is read-only. However,= =20 target description can't handle Orjan's requirement (changing the bank sele= ct=20 register changes the contents for a whole set of other registers.). My original thought is to extend observer 'target_changed' to pass more=20 parameters, such as 'register number', and backend registers its own hook t= o=20 'target_changed' observer, and takes right actions for the "interesting"=20 register changes. Maybe we can do this via gdbarch hook. THe problem is clear, but its description is not very precise. I don't hav= e a=20 solid plan so far. --=20 Yao (=E9=BD=90=E5=B0=A7)