From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19886 invoked by alias); 19 Nov 2002 09:20:54 -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 19864 invoked from network); 19 Nov 2002 09:20:52 -0000 Received: from unknown (HELO dublin.ACT-Europe.FR) (212.157.227.154) by sources.redhat.com with SMTP; 19 Nov 2002 09:20:52 -0000 Received: from torino.act-europe.fr (torino.int.act-europe.fr [10.10.0.130]) by dublin.ACT-Europe.FR (Postfix) with ESMTP id 57120229E15; Tue, 19 Nov 2002 10:20:51 +0100 (MET) Received: by torino.act-europe.fr (Postfix, from userid 500) id 1B87CF404; Tue, 19 Nov 2002 14:20:51 +0500 (GMT-5) Date: Tue, 19 Nov 2002 01:20:00 -0000 From: Romain Berrendonner To: Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: compatibility between gdb and stub Message-ID: <20021119092051.GD1217@torino.act-europe.fr> References: <20021118140945.GF1252@torino.act-europe.fr> <1021118225613.ZM5538@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1021118225613.ZM5538@localhost.localdomain> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00210.txt.bz2 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. Don't hesitate to correct me if I'm wrong :-) -- Romain