From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18663 invoked by alias); 6 Jul 2004 17:43:07 -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 18656 invoked from network); 6 Jul 2004 17:43:07 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 6 Jul 2004 17:43:07 -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 i66Hh6e3019331 for ; Tue, 6 Jul 2004 13:43:07 -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 i66Hh6025706; Tue, 6 Jul 2004 13:43:06 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 337A82B9D; Tue, 6 Jul 2004 13:42:54 -0400 (EDT) Message-ID: <40EAE49E.7040304@gnu.org> Date: Tue, 06 Jul 2004 17:43: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 Cc: Jim Blandy , 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> In-Reply-To: <20040706153826.GB11822@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00048.txt.bz2 >>> (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. Andrew