From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26118 invoked by alias); 6 Jul 2004 18:31: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 26104 invoked from network); 6 Jul 2004 18:31:34 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 6 Jul 2004 18:31:34 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Bhuip-0000ht-Cp; Tue, 06 Jul 2004 14:31:15 -0400 Date: Tue, 06 Jul 2004 18:31:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: RFA: make sim interface use gdbarch methods for collect/supply Message-ID: <20040706183115.GA2685@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Blandy , 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> <40EAE49E.7040304@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40EAE49E.7040304@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-07/txt/msg00051.txt.bz2 On Tue, Jul 06, 2004 at 01:42:54PM -0400, Andrew Cagney wrote: > > >>>(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? > > No. But going forward we've got to dig our way out of the G/T packet > bear trap. > > >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. > > From memory, the only thing missing is code to parse a regformats file. I did eventually intend for them to be used by the client. I'll try to find some round tuits. -- Daniel Jacobowitz