From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3748 invoked by alias); 4 May 2004 17:56:01 -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 3714 invoked from network); 4 May 2004 17:55:59 -0000 Received: from unknown (HELO zcamail03.zca.compaq.com) (161.114.32.103) by sources.redhat.com with SMTP; 4 May 2004 17:55:59 -0000 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 2FCF4DD9; Tue, 4 May 2004 10:55:59 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 6249C3BE0; Tue, 4 May 2004 12:55:58 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id NAA0001488854; Tue, 4 May 2004 13:55:53 -0400 (EDT) Message-ID: <4097D9DE.2030004@hp.com> Date: Tue, 04 May 2004 17:56:00 -0000 From: Robert Picco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 MIME-Version: 1.0 To: Andrew Cagney 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> <40928D64.8010209@gnu.org> In-Reply-To: <40928D64.8010209@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00112.txt.bz2 Andrew Cagney wrote: >> 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 > > Hi: Well I must admit to being a little confused:) My intent is to not introduce any architecture dependency in remote.c and just restructure the g-packet to match what the target wants. I could be missing a point here but the regset stuff looks very architecture dependent and it would seem incorrect to use it in remote.c. Well for offset I am using the regnum. We are inquirying whether the target wants the reg mapped in the g-packet . We could fetch lazy but this isn't currently done by remote.c because most target g-packet payloads aren't very large. IA64 is the exception with a payload in excess of 10,000 bytes. I must be missing your larger objective here because my limited knowledge of gdb is in remote.c. thanks, Bob