From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32406 invoked by alias); 6 Jul 2004 17:17: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 32357 invoked from network); 6 Jul 2004 17:17:05 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 6 Jul 2004 17:17:05 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BhtYk-0000AN-Gf; Tue, 06 Jul 2004 13:16:46 -0400 Date: Tue, 06 Jul 2004 17:17: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: <20040706171646.GA595@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew Cagney , gdb-patches@sources.redhat.com 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> 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/msg00047.txt.bz2 On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Fri, Jul 02, 2004 at 11:39:41AM -0400, Andrew Cagney wrote: > > > >On Thu, Jul 01, 2004 at 01:44:53PM -0500, Jim Blandy wrote: > > > > > > > >>> > > > >>>Daniel Jacobowitz writes: > > > >> > > > >>>>> 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? > > > >> > > > >>> > > > >>>No, regsets are perfect for 'g'. I was thinking of the single- > > > >>>register case (all under the assumption that we'd like to restrict > > > >>>uses of supply_register and collect_register to regset functions). > > > >>>What do you do with, say, the individual registers from your fancy 'T' > > > >>>reply? > > > > > > > > > > > >I have no idea. Good question. > > > > > > (I've attached a few of comments that go with TARGET_OBJECT, check the > > > archives for qPart) > > > > > > For regsets, the ``void *buffer/long length'' pair can be replaced by a > > > single ``byte array'' object. > > > > > > The regset code can then send offset/length xfer requests to that ``byte > > > array''. For cores, the byte array would extract the bytes from the > > > core file; for ptrace, the byte array would extract the bytes using the > > > relevant ptrace call; and for the remote inferior, the request would be > > > converted into one or more qPart packets (sending the > > > regset/offset/length across the wire). > > > > > > When it comes to a `T' reply, the remote inferior can push > > > regset/offset/length data for parts of the regset buffer that it thinks > > > are interesting. > > > > If I'm interpreting your answer right, it is: "don't do anything about > > it, change the remote protocol instead", right? > > > > 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. Or have the register renumbering function map that number to the combined pseudo register! -- Daniel Jacobowitz