From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7426 invoked by alias); 29 Jan 2002 19:31:28 -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 7377 invoked from network); 29 Jan 2002 19:31:26 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 29 Jan 2002 19:31:26 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA19295; Tue, 29 Jan 2002 11:31:25 -0800 (PST) Message-ID: <3C56F701.8869B52F@redhat.com> Date: Tue, 29 Jan 2002 11:31:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] legacy_[read/write]_register_gen References: <200201290102.g0T12Uk24471@reddwarf.cygnus.com> <3C5614AF.4050809@cygnus.com> <3C56EC48.8ACAC16B@redhat.com> <3C56F660.5040902@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00762.txt.bz2 Andrew Cagney wrote: > > > Simplest case -- say you want to have a pseudo-register that > > mirrors the contents of a real register. > > > > static void > > my_fetch_pseudo_register (int regnum) > > { > > if (regnum == MY_MIRROR_REGNUM) > > { > > char buf[REGISTER_SIZE]; > > regcache_read (MY_REAL_REGNUM, buf); > > regcache_write (MY_MIRROR_REGNUM, buf); > > } > > } > > > > You can't do that unles legacy_write_register_bytes can address > > the regcache location of your pseudo-register. > > That should be implemented as: > > my_register_read (int regnum, ...) > { > if (regnum == MY_MIRROR_REGNUM) > regcache_read (MY_REAL_REGNUM, buf) > else > regcache_read (regnum, buf); > } > > GDB no longer needs to have duplicated register values in the regcache. > > Anyway, I have figured out why the change is needed. You can end up > with ``real'' registers in the [NUM_REGS .. NUM_REGS+NUM_PSEUDO_REGS) > range. This happens (at present still theory) when a register that > isn't in the G packet is fetched. Shall I check it in?