From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14937 invoked by alias); 26 Nov 2002 21:56:38 -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 14922 invoked from network); 26 Nov 2002 21:56:36 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 26 Nov 2002 21:56:36 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E98093F30; Tue, 26 Nov 2002 16:56:30 -0500 (EST) Message-ID: <3DE3EE0E.4010009@redhat.com> Date: Tue, 26 Nov 2002 13:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Romain Berrendonner Cc: Kevin Buettner , gdb@sources.redhat.com Subject: Re: compatibility between gdb and stub References: <20021118140945.GF1252@torino.act-europe.fr> <1021118225613.ZM5538@localhost.localdomain> <20021119092051.GD1217@torino.act-europe.fr> <1021120210450.ZM24337@localhost.localdomain> <20021121094419.GB8709@torino.act-europe.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00370.txt.bz2 > On 2002-11-20, Kevin Buettner wrote : > > >> >> As I understand it, if a stub replies with a short "g" packet, then >> gdb will simply regard the missing registers as being unavailable. >> > > Let's take the example of the 750, with a stub not aware of fpscr. /* Motorola/IBM PowerPC 750 or 740. */ static const struct reg registers_750[] = { COMMON_UISA_REGS, PPC_UISA_SPRS, PPC_SEGMENT_REGS, PPC_OEA_SPRS, /* 119 */ R(hid0), R(hid1), R(iabr), R(dabr), /* 123 */ R0, R(ummcr0), R(upmc1), R(upmc2), /* 127 */ R(usia), R(ummcr1), R(upmc3), R(upmc4), /* 131 */ R(mmcr0), R(pmc1), R(pmc2), R(sia), /* 135 */ R(mmcr1), R(pmc3), R(pmc4), R(l2cr), /* 139 */ R(ictc), R(thrm1), R(thrm2), R(thrm3) }; /* UISA-level SPRs for PowerPC. */ #define PPC_UISA_SPRS \ /* 66 */ R4(cr), R(lr), R(ctr), R4(xer), R4(fpscr) So `fpscr' is 70 and it goes with the comment: Note: kevinb/2002-04-30: Support for the fpscr register was added during April, 2002. Slot 70 is being used for PowerPC and slot 71 for Power. For PowerPC, slot 70 was unused and was already in the PPC_UISA_SPRS which is ideally where fpscr should go. For Power, slot 70 was being used for "mq", so the next available slot (71) was chosen. It would have been nice to be able to make the register numbers the same across processor cores, but this wasn't possible without either 1) renumbering some registers for some processors or 2) assigning fpscr to a really high slot that's larger than any current register number. Doing (1) is bad because existing stubs would break. Doing (2) is undesirable because it would introduce a really large gap between fpscr and the rest of the registers for most processors. */ > They are many registers after fpscr (the first of them is sr0). > With this scheme, when the stub sends back the answer to a 'g' packet, > gdb will consider that the content of fpscr is the content of sr0, and that > thrm3 (the last register) is not available. No. An old stub would supply zeros instead of "fpscr". > This is clumsy, but the 'qRegisters' packet should improve this behaviour :-) qRegisters isn't a `silver bullet' :-/ The bottom line is that GDB and the stub need to agree to a packet layout and then stick to it. Andrew