From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6769 invoked by alias); 1 Jul 2004 02:48:35 -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 6758 invoked from network); 1 Jul 2004 02:48:32 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 1 Jul 2004 02:48:32 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Bfrcd-0001bh-Az; Wed, 30 Jun 2004 22:48:23 -0400 Date: Thu, 01 Jul 2004 02:48:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: make sim interface use gdbarch methods for collect/supply Message-ID: <20040701024822.GA5875@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20040630155329.GA19452@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-07/txt/msg00001.txt.bz2 On Wed, Jun 30, 2004 at 12:00:16PM -0500, Jim Blandy wrote: > Daniel Jacobowitz writes: > > > On Wed, Jun 30, 2004 at 10:47:23AM -0500, Jim Blandy wrote: > > > > > > At the moment, remote-sim.c's gdbsim_fetch_register and > > > gdbsim_store_register functions assume that the simulator's register > > > set (as visible via sim_fetch_register and sim_store_register) > > > corresponds exactly to GDB's raw register set. This patch is meant to > > > remove that assumption. > > > > > > Tested on i686-pc-linux-gnu x powerpc-eabispe (sim). > > > > We've got a whole lot of new mechanism for describing register sets. > > Can't you use that instead of adding new supply/collect routines? > > I'd love to use some existing mechanism, but I couldn't see how to > apply what I know of to this problem. Can you give me a pointer? > > If you mean the regset stuff: the sim doesn't present its registers in > terms of a single structure that one could pass to a > supply_regset_ftype or collect_regset_ftype value; you make one call > to a sim function to transfer each register. The interface may need some surgery to do it, but the sim's registers are conceptually a regset, aren't they? We could collect each register from the sim into a buffer and write a "struct regset" describing that. This could happen in an arch-independent way in remote-sim, and then the regset be provided by the target architecture. > I think what you're getting at is that SIM_COLLECT_REGISTER and > SIM_SUPPLY_REGISTER will in general have to re-implement some of the > raw/pseudo mapping. I agree that that's unfortunate, but it's > inherent in the design: we can only collect and supply raw register > values, and our raw regcache layout is not necessarily the same as the > sim's register layout. No, what I'm getting at is that I'd rather the number of interfaces for accessing registers went down than up! I want to standardize on using the regset interface, because it's the most flexible. -- Daniel Jacobowitz