From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2638 invoked by alias); 1 Jul 2004 17:31:09 -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 2631 invoked from network); 1 Jul 2004 17:31:08 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 1 Jul 2004 17:31:08 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Bg5Op-0003tJ-6f; Thu, 01 Jul 2004 13:31:03 -0400 Date: Thu, 01 Jul 2004 17:31: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: <20040701173102.GA14843@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20040630155329.GA19452@nevyn.them.org> <20040701024822.GA5875@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/msg00007.txt.bz2 On Thu, Jul 01, 2004 at 12:22:25PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > > 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. > > Grumble. > > So you're setting forth as an ideal that remote-sim.c would stop using > supply_register and collect_register altogether, and just use a > regset's supply and collect functions, right? > > The regset interface isn't very well-suited for single-register > accesses. Only the regset's collect and supply functions know which > bytes of the buffer are going to be used to supply a particular raw > register's value. So when gdbsim_fetch_register is passed a specific > raw register number, it has no way of knowing which bytes of the > buffer to populate from the sim before it invokes the regset's supply > function. For it to know that, it needs to know the correspondence > between the raw register cache and the cooked form provided by the > target --- but the whole point of introducing regsets in the first > place was to isolate that knowledge in regset supply and collect > functions. So the sim would need to always read a full sim regset, > even when only one register was requested. OK, that's a legitimate reason not to use regsets for this. A reason was all I wanted :) I still think it might be advantageous to always fetch all registers for the sim case, though, and use regsets anyway. We already do this for many native targets (PTRACE_GETREGS) because that's lowest latency. > For the sim, that might all be in the noise, and not matter. But if > you want to push the same sort of change through remote.c, then you > can't use that workaround. For now, GDB's internal raw regcache > layout must correspond exactly to that of the 'g' packet, but I assume > that's not supposed to hold forever. So when the remote protocol > registers don't exactly correspond to raw regcache registers, how will > GDB know where to place their contents in the buffer before calling > the supply function? > > At the moment, regsets are used only to transfer entire register sets, > so we haven't run into it. GDB won't have to know where to place their contents in the buffer! That's the point of using a regset. You convert the 'g' packet output to a binary blob in the obvious way, and then that's your regset. The target architecture supplies a regset that expects the format provided by the 'g' packet. Is there some problem with that plan? -- Daniel Jacobowitz