From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10264 invoked by alias); 9 Jun 2004 15:43:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10204 invoked from network); 9 Jun 2004 15:43:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Jun 2004 15:43:49 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i59Fhmi7017352 for ; Wed, 9 Jun 2004 11:43:48 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i59Fhl019957; Wed, 9 Jun 2004 11:43:48 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0A7752B9D; Wed, 9 Jun 2004 11:43:42 -0400 (EDT) Message-ID: <40C7302D.9020506@gnu.org> Date: Wed, 09 Jun 2004 15:43: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: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: Supplying regsets containing pseudoregisters References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00069.txt.bz2 > I think I've run into a design problem in the interaction between the > "supply" functions that move data from target-specific sources like > ptrace and core files to the regcache, and the pseudoregister support. > > The job of a regset's "supply" function is to (essentially) call > regcache_raw_supply on the selected register from the regset, or on > all the registers in the regset if the register number is -1. > regcache_raw_supply drops the register's bits into the regcache. > regcache_raw_supply only allows its callers to supply values of raw > registers. FYI, this was a design decision - the low code supplying / collecting registers only manipulates the raw register cache. The old code, which tried to implement pseudo-registers in the supply / collect code, didn't enforce this, and the result was a mess. > But sometimes the values in a regset correspond to pseudoregisters. > For example, on the PowerPC E500, the general-purpose registers are 64 > bits wide, but the E500 doesn't implement the normal PPC 64-bit > integer instructions; the only instructions which access the upper 32 > bits are special SIMD vector instructions. GDB represents E500 gprs > as pseudoregisters stored in the lower halves of the ev0--ev31 > registers, which are raw registers each 64 bits long. On E500 Linux, > a gregset_t (as found in a core file, or as handled by libthread_db) > contains the values of the 32-bit GPRs, not the 64-bit EV registers. > So the 'supply' function for such a regset has pseudoregister values, > but because of regcache_raw_supply's interface, it needs to supply raw > register values. It sounds like the regcache layout needs to be changed. I'd break the raw EV registers down into hi:lo pairs so that each part can be supplied separatly - this appears to more closely reflect the underlying implementation. Andrew