From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30944 invoked by alias); 19 Nov 2002 01:43:49 -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 30937 invoked from network); 19 Nov 2002 01:43:48 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Nov 2002 01:43:48 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18DzId-0001zE-00; Mon, 18 Nov 2002 21:43:43 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18DxRb-0004yS-00; Mon, 18 Nov 2002 20:44:51 -0500 Date: Mon, 18 Nov 2002 17:43:00 -0000 From: Daniel Jacobowitz To: Steven Johnson Cc: gdb@sources.redhat.com Subject: Re: compatibility between gdb and stub Message-ID: <20021119014451.GA19102@nevyn.them.org> Mail-Followup-To: Steven Johnson , gdb@sources.redhat.com References: <20021118140945.GF1252@torino.act-europe.fr> <1021118225613.ZM5538@localhost.localdomain> <3DD99530.4040605@neurizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD99530.4040605@neurizon.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00201.txt.bz2 On Tue, Nov 19, 2002 at 11:34:40AM +1000, Steven Johnson wrote: > I had this problem as well, for the MPC860 target. > > The fpscr didn't used to be required, but now it is. The result was > that all registers below it were shifted up by one. I actually noticed > it because the PVR was telling me zero, which is an invalid processor > version. I fixed it by changing my stub, but it was annoying. > > The other thing that is annoying is the generic powerpc target wont work > with a MPC860 stub and vice versa. What would be nice is a query > mechanism where at connection, GDB can say "I want these registers" and > the stub can return "Thats fine, but of the registers you want, these > are the ones i support." Then in a block registers response or write > from/to the target, the registers would be sent and received in the > order they appeared. This could also set the value of the index for N > for the p/P packets. > > something like (for a pretend processor): > > qRegisters:pc,32;sp,32;flags,16;fpflags,16;r0,32;r1,32;r2,32;r3,32;r4,32; > r5,32;r6,32;r7,32;r8,32;f0,64;f1,64;f2,64;f3,64;f4,64;f5,64;f6,64;f7,64;f8,64; > > which for a stub that runs on a varient of the processor without > floating point would respond: > > qRegisters:pc,32;sp,32;flags,16;r0,32;r1,32;r2,32;r3,32;r4,32; > r5,32;r6,32;r7,32;r8,32; > > if the stub supported more registers than GDB asked for, then the stub > would just not return them. If the stub was an old stub and didn't > support this, then GDB would not get the qRegisters response, and so > would not reduce it's expectations of what registers it could use in a > stub. And so would work as it does now. > > Then the index for p/p would be: > pc = 0 > sp = 1 > r4 = 7 > and so on. > > There would be performance advantages to this scheme as well, because > currently stubs are required to return registers that their target does > not support. For example, the powerpc:MPC860 target does not support > floating point, but the stub is still required to return them, and there > are 32 of them and they are 64 bits wide!! > > This would also allow the not so great statement in the description of > the 'g' packet: "The size of each register and their position within the > 'g' PACKET are determined by the GDB internal macros' to be replaced > with something more concrete like: see qRegisters for details of the > order and size of registers, stubs that do not support qRegisters must > refer to GDB internal macros. > > What do people think? Everyone agrees. I've even posted an implementation of qRegisters that's a simplified version of the above. But that patch is out of date now and Andrew wanted something more flexible at the time, IIRC... I suspect we're getting closer and someone just needs to do the work again. > > Steven Johnson > > 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? > > > >Kevin > > > > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer