From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32500 invoked by alias); 27 Nov 2002 00:01:21 -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 32437 invoked from network); 27 Nov 2002 00:01:19 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 27 Nov 2002 00:01:19 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BA38B3F30; Tue, 26 Nov 2002 19:01:13 -0500 (EST) Message-ID: <3DE40B49.70405@redhat.com> Date: Tue, 26 Nov 2002 16:01: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: Steven Johnson Cc: 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> <3DE3EE0E.4010009@redhat.com> <3DE40436.4060102@neurizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00379.txt.bz2 > The real problem here is that the Common Registers of PowerPC are not uniform across the chips. I think the only ones that can truly be said to be common are R0-R31,pc,msr,lr,ctr,flags The macros defined, assume a whole lot about what is common, that isn't. > > And having written an "old stub" for the MPC860, I can confidently say that old stubs did not supply zeros where fpscr is, they didn't send anything as GDB did not expect anything. That is fine. New registers get added to the end. Consequently, an old target (which knows zip about those registers) would send what GDB views as a short packet. GDB would mark the missing registers (which should have been at the end of the packet) as being zero. > Obviously there would need to be some understanding in the stub of what registers GDB used, but I fail to see that GDB is ever going to permenantly define a packet layout and stick to it. Part of the definition is that the packet can grow and grow and grow. You just can't go back and re-format it. The outstanding change, though, is for GDB to allow sparse register numbers in the remote protocol. The P4, for instance, has two thousand million potential MSR registers. Such registers would need to be fetched using something other than the [gG] packet (i.e., the [Pp] packets). Andrew