From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19532 invoked by alias); 20 Nov 2002 21:04:59 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19525 invoked from network); 20 Nov 2002 21:04:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 20 Nov 2002 21:04:58 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gAKKf4P05870 for ; Wed, 20 Nov 2002 15:41:04 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gAKL4vD22628; Wed, 20 Nov 2002 16:04:57 -0500 Received: from localhost.localdomain (vpn50-31.rdu.redhat.com [172.16.50.31]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gAKL4uw01988; Wed, 20 Nov 2002 16:04:56 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id gAKL4oQ24338; Wed, 20 Nov 2002 14:04:50 -0700 Date: Wed, 20 Nov 2002 13:04:00 -0000 From: Kevin Buettner Message-Id: <1021120210450.ZM24337@localhost.localdomain> In-Reply-To: Romain Berrendonner "Re: compatibility between gdb and stub" (Nov 19, 10:20am) References: <20021118140945.GF1252@torino.act-europe.fr> <1021118225613.ZM5538@localhost.localdomain> <20021119092051.GD1217@torino.act-europe.fr> To: Romain Berrendonner Subject: Re: compatibility between gdb and stub Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00295.txt.bz2 On Nov 19, 10:20am, Romain Berrendonner wrote: > On 2002-11-18, Kevin Buettner wrote : > > > On Nov 18, 3:09pm, Romain Berrendonner wrote: > > > > > The file rs6000-tdep.c however, which was very similar in gdb 5.1 and > > > gdb 5.2, changed in the 5.3 branch, causing interoperability disruption > > > with older stubs, due to the definition of fpscr. > > > > It was my intent to add fpscr in such a way so that existing stubs > > would not be broken. It sounds like I didn't succeed. Can you explain > > the problem that you're seeing? > > Here's my understanding of how the 'G' and 'g' commands work: > > 1/ gdb has a list of all registers for the variant of processor it is > currently using. Each register has a size (4 or 8 bytes). > > 2/ When it need to send a 'G' packet, it concatenates the contents of > all the registers, as specified in the definition: the number of > registers, their size and their order matters. Conversely, when it needs > to parse a 'g' packet, it knows the value of each registers by the value > of the bytes corresponding to its position in the data flow. > > Now, I have a stub working with 5.1, and I'm considering using it with 5.3. > In rs6000-tdep.c for gdb 5.1 we got: > > #define PPC_UISA_SPRS \ > /* 66 */ R4(cr), R(lr), R(ctr), R4(xer), R0 > > In rs6000-tdep.c for gdb 5.3 we got: > > #define PPC_UISA_SPRS \ > /* 66 */ R4(cr), R(lr), R(ctr), R4(xer), R4(fpscr) > > So the slot 70 is now used, while it was empty before. This is why I suspected > a non-compatibility with older stubs. As I understand it, if a stub replies with a short "g" packet, then gdb will simply regard the missing registers as being unavailable. Kevin