From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25294 invoked by alias); 30 Apr 2004 17:31:24 -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 25287 invoked from network); 30 Apr 2004 17:31:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 30 Apr 2004 17:31:24 -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 i3UHVNKI010644 for ; Fri, 30 Apr 2004 13:31:23 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3UHVFv07185; Fri, 30 Apr 2004 13:31:22 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7BF992B9D; Fri, 30 Apr 2004 13:31:16 -0400 (EDT) Message-ID: <40928D64.8010209@gnu.org> Date: Fri, 30 Apr 2004 17:31: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: Robert Picco Cc: gdb-patches@sources.redhat.com Subject: Re: new gdb remote packet type References: <407F2BAB.4060408@hp.com> <40802711.3040104@gnu.org> <4087E8C0.30806@hp.com> <4087EE4B.4010805@gnu.org> <40912015.7070902@hp.com> In-Reply-To: <40912015.7070902@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00710.txt.bz2 > Andrew Cagney wrote: > >>> you'd prefer that I use the q-packet mechanism? >> >> >> >> Yes, the qPart packet was designed for exactly the situtation you encountered. It can specify a length/offset and return a short transfer. >> >> Andrew >> >> > Hi: > > Does this represent what you are expecting of the qPart packet? I saw no reason to export the type because this > packet is only useful in remote.c While not immediatly, it is going to eventually be exposed out side of remote.c, so we need to get what goes across the wire right up front. To that end: - use register sets Unlike the G-packet, where the byte layout is determined by GDB internal data structure, the byte layout needs to be specified by the inferior's regsets. That in turn means specifying separate packets for fetching all or part of each of "gregs", "fpregs", and "xpregs"(?). - specify offset/length I think your code is specifying a register number, it should view the region as a sequence of bytes and fetch using offset/length. This information can be obtained using "regset.h" (although that interface might need some massaging). - fetch lazy Just request the region for the requested register. It's then up to the remote end to determine that more/less of the region can be supplied. Eventually this will also be added to the target vector, however, for the moment something more local is definitly fine. Andrew