From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5238 invoked by alias); 8 Jun 2004 23:46:44 -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 5221 invoked from network); 8 Jun 2004 23:46:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Jun 2004 23:46:43 -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 i58Nkgi5014307 for ; Tue, 8 Jun 2004 19:46:42 -0400 Received: from zenia.home.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 i58Nke019098; Tue, 8 Jun 2004 19:46:41 -0400 To: gdb@sources.redhat.com Subject: Supplying regsets containing pseudoregisters From: Jim Blandy Date: Tue, 08 Jun 2004 23:46:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-06/txt/msg00055.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. So there's an assumption that regset contains raw register values. 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. The supply function can certainly do the cooked->raw form conversion itself, but that would be a duplication of the code in the existing pseudo_register_write function. Unfortunately, pseudo_register_write functions are defined work by writing to the underlying raw registers with regcache_raw_write and friends, which ends up calling target_store_registers, which isn't the sort of behavior a supply function wants. Ideally, the definition raw/pseudo relationship could be localized to one set of functions. But it looks to me as if regset supply functions need to implement it too. I can certainly break out the PPC pseudo/raw correspondence into functions that take the raw read/write functions as parameters, and pass regcache_raw_supply when I'm supplying a regcache, and regcache_raw_write when I'm writing a pseudoregister. That would keep the correspondence localized to one set of functions, but it feels to me like begging the question: there's no intrinsic reason to assume that what GDB developers decide to call raw registers will always match what OS developers decide to put in gregset_t and fpregset_t. What's the thinking on this?