From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19801 invoked by alias); 2 Jul 2004 15:39:55 -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 19792 invoked from network); 2 Jul 2004 15:39:53 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Jul 2004 15:39:53 -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 i62Fdre3010664 for ; Fri, 2 Jul 2004 11:39:53 -0400 Received: from localhost.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 i62Fdq008180; Fri, 2 Jul 2004 11:39:52 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 499642B9D; Fri, 2 Jul 2004 11:39:41 -0400 (EDT) Message-ID: <40E581BD.6010405@gnu.org> Date: Fri, 02 Jul 2004 15:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz , Jim Blandy Cc: 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> In-Reply-To: <20040701184832.GA18339@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00017.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. (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. >>> 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. Andrew /* Request the transfer of up to LEN 8-bit bytes of the target's OBJECT. The OFFSET, for a seekable object, specifies the starting point. The ANNEX can be used to provide additional data-specific information to the target. Return the number of bytes actually transfered, zero when no further transfer is possible, and -1 when the transfer is not supported. NOTE: cagney/2003-10-17: The current interface does not support a "retry" mechanism. Instead it assumes that at least one byte will be transfered on each call. NOTE: cagney/2003-10-17: The current interface can lead to fragmented transfers. Lower target levels should not implement hacks, such as enlarging the transfer, in an attempt to compensate for this. Instead, the target stack should be extended so that it implements supply/collect methods and a look-aside object cache. With that available, the lowest target can safely and freely "push" data up the stack.