From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1324 invoked by alias); 1 Jul 2004 18:48:39 -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 1167 invoked from network); 1 Jul 2004 18:48:38 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 1 Jul 2004 18:48:38 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Bg6bo-0004rL-Ou; Thu, 01 Jul 2004 14:48:33 -0400 Date: Thu, 01 Jul 2004 18:48: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: <20040701184832.GA18339@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20040630155329.GA19452@nevyn.them.org> <20040701024822.GA5875@nevyn.them.org> <20040701173102.GA14843@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/msg00010.txt.bz2 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. > > As far as I can tell, regsets don't serve this case well, which makes > them (in their current state) less than suitable as a universal > register transfer interface. > > -- Daniel Jacobowitz