From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24150 invoked by alias); 16 Jul 2004 15:01:15 -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 24140 invoked from network); 16 Jul 2004 15:01:14 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 16 Jul 2004 15:01:14 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BlUCL-0002FO-N1; Fri, 16 Jul 2004 11:00:29 -0400 Date: Fri, 16 Jul 2004 15:01:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: RFA: make sim interface use gdbarch methods for collect/supply Message-ID: <20040716150029.GA8442@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew Cagney , gdb-patches@sources.redhat.com References: <20040701024822.GA5875@nevyn.them.org> <20040701173102.GA14843@nevyn.them.org> <20040701184832.GA18339@nevyn.them.org> <40E581BD.6010405@gnu.org> <20040706153826.GB11822@nevyn.them.org> <20040706171646.GA595@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/msg00195.txt.bz2 On Thu, Jul 15, 2004 at 01:30:22PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote: > > > Daniel Jacobowitz writes: > > > > A more practical approach would probably be to maintain a mapping of > > > > the remote protocol register numbers to GDB's internal register numbers > > > > in addition to register sets. I don't see any problem with that. > > > > > > What if the remote protocol wants to talk about a 64-bit register, but > > > GDB's raw regcache sees that as two 32-bit registers? A simple > > > number-to-number mapping doesn't do the trick. > > > > Don't do that then. Pass those as a regset, not numbered in the T > > packet. > > You're saying that, since we include register values in the T packet > just for expedience, we can always decline to do that when it's hard, > right? But whether it's hard or not depends on GDB's raw regcache > layout, which isn't supposed to be a matter of public interface. When > someone needs to rearrange the raw regcache, the set of registers > which can be profitably provided in a T packet changes. That's not > the way it should be. > > > Or have the register renumbering function map that number to the > > combined pseudo register! > > But what would GDB's code handling that packet do with that pseudo- > register number? It can't pass it to a regset or per-register > "supply" function. Then perhaps that should be changed. In practice, many pseudo-registers are suppliable. It might even be possible to rearrange the interfaces such that *_pseudo_register_write can be used, via regcache_cooked_write, i.e. supply cooked registers. This would require rethinking of the raw/cooked boundary. Currently the boundary is that raw registers are those we can query the target for. If you have a remote target that can not supply the same registers we keep in the raw regcache, we have a design problem. -- Daniel Jacobowitz