From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28765 invoked by alias); 1 Jul 2004 17:23:16 -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 28739 invoked from network); 1 Jul 2004 17:23:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 1 Jul 2004 17:23:14 -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 i61HNEe1021980 for ; Thu, 1 Jul 2004 13:23:14 -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 i61HNC005312; Thu, 1 Jul 2004 13:23:12 -0400 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: make sim interface use gdbarch methods for collect/supply References: <20040630155329.GA19452@nevyn.them.org> <20040701024822.GA5875@nevyn.them.org> From: Jim Blandy Date: Thu, 01 Jul 2004 17:23:00 -0000 In-Reply-To: <20040701024822.GA5875@nevyn.them.org> 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-07/txt/msg00006.txt.bz2 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. 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.