From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25895 invoked by alias); 21 Apr 2004 16:48:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23332 invoked from network); 21 Apr 2004 16:46:14 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 21 Apr 2004 16:46:14 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7AC7C2B9D; Wed, 21 Apr 2004 12:22:28 -0400 (EDT) Message-ID: <40869FC4.2090407@gnu.org> Date: Wed, 21 Apr 2004 16:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: Multiplexed registers and invalidating the register cache References: <407D242B.109@axis.com> <20040414144607.GA5700@nevyn.them.org> <407E67EA.80701@axis.com> <407E70FD.7060709@axis.com> <407EAA4B.7000500@gnu.org> <407FD693.2080804@axis.com> <408030DB.3080708@gnu.org> <4083DE9C.7000208@axis.com> In-Reply-To: <4083DE9C.7000208@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00493.txt.bz2 > Andrew Cagney wrote: > >> >> - the frame cache is built on-demand, hence the absence of any explict rebuild call (one characteristic of a frame ID is that it survives frame cache flushes) > > > In other words, I shouldn't expect to see a whole lot of communication with the remote target simply because I flush the frame cache. Yes. >> - there shouldn't be separate register and frame flush calls, combining the two into a single observer call is a thing-to-do-today > > > Ok, let's see if I understand this correctly. Sorry if I'm asking what is (or should be) obvious (I only see observer.exp using this code as of now, so it's not clear to me how this is supposed to be used within GDB). > > A new event needs to be defined (user_changed_registers(?), taking the register number as an argument). This will give us attach/detach/notify functions related to that event. So, someone needs to attach a callback: is this something that should be done in target-specific files? Simpler, "target_changed" - no parameters. > If so, should targets provide their own callback implementation (which flushes the register and frame cache when deemed appropriate), or should there be a predefined function that the target-specific file simply references when attaching the callback? The core code, after doing the write, should trigger this event ... > In addition, someone needs to notify that the event has happened, but I assume these notifications should be inserted at the same places that register_changed_hook is called for GUI purposes. ... [yes] replacing registers changed. > Anything I missed or misunderstood? No, you've got the theory. Andrew