From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27853 invoked by alias); 15 Jul 2004 18:35:34 -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 27832 invoked from network); 15 Jul 2004 18:35:33 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Jul 2004 18:35:33 -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 i6FIZXe1013071 for ; Thu, 15 Jul 2004 14:35:33 -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 i6FIZV007568; Thu, 15 Jul 2004 14:35:32 -0400 To: Daniel Jacobowitz Cc: Andrew Cagney , 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> <20040701173102.GA14843@nevyn.them.org> <20040701184832.GA18339@nevyn.them.org> <40E581BD.6010405@gnu.org> <20040706153826.GB11822@nevyn.them.org> <20040706171646.GA595@nevyn.them.org> From: Jim Blandy Date: Thu, 15 Jul 2004 18:35:00 -0000 In-Reply-To: <20040706171646.GA595@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/msg00186.txt.bz2 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.