From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1576 invoked by alias); 20 Dec 2007 17:21:31 -0000 Received: (qmail 1566 invoked by uid 22791); 20 Dec 2007 17:21:30 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Dec 2007 17:21:23 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 3A2D898151; Thu, 20 Dec 2007 17:21:21 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 04DE998150; Thu, 20 Dec 2007 17:21:21 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J5P5E-0004zt-3x; Thu, 20 Dec 2007 12:21:20 -0500 Date: Thu, 20 Dec 2007 17:22:00 -0000 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org, Nigel Stephens , David Ung , "Maciej W. Rozycki" Subject: Re: mips-tdep.c: Unification of FPR size detection Message-ID: <20071220172120.GC17663@caradoc.them.org> Mail-Followup-To: "Maciej W. Rozycki" , gdb-patches@sourceware.org, Nigel Stephens , David Ung , "Maciej W. Rozycki" References: <20071216212504.GK22905@caradoc.them.org> <20071219171530.GA4896@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00349.txt.bz2 On Thu, Dec 20, 2007 at 04:57:11PM +0000, Maciej W. Rozycki wrote: > This patch in its current form assumes if no frame is available, then the > width of the registers is irrelevant and because some value has to be > provided it uses the native one. The value you provide then (probably during regcache creation) will stick around longer than you expect. > > Right. But it doesn't change the size of the registers as presented > > by a remote stub to GDB. So, for our purposes I think the best model > > is that the size of the raw FP registers does not change. How can we > > change the size of the raw registers while the stub is sending the > > same bit patterns to GDB? > > This sounds like a bug in the stub then -- probably an outcome from the > semantics of the "ldc1/sdc1" instructions which it may use rather than > exposing the actual topology of the register file. It may have worked > reasonably well for legacy MIPS processors, because odd-numbered FP > registers were only usable as a high-part of double values, so the FPU > could have been effectively treated as one having 16 64-bit FPRs split in > an original way. I'm not talking about the implementation of a stub; I'm talking about the remote serial protocol and GDB<->stub communications. One thing we simply can not do is change the size of the registers in the middle of a debugging session. If we do, GDB will have no way to parse the resulting 'g' packet and locate the status register to check FR. Some background to be sure we're using the same terminology: The MIPS port is currently organized with two sets of registers. One is the raw registers, those provided by hardware. The other is the ABI registers, those defined by the current ABI. The raw registers are always used to communicate with the target. The ABI registers are always used to communicate with the user. $f0 is always an ABI register and its size is always determined by the ABI. Ideally, the target would define the raw registers and the gdbarch would define the ABI registers. In practice it's messier than that, but that's how it's supposed to work. You are trying to distinguish the raw registers, used for communication, from the hardware registers, which effectively change under software control. The port is not prepared for that. The only mechanism we have to report different sizes for registers is the creation of a new gdbarch; it seems like the two settings of the FR bit should correspond to two different gdbarches. But selecting a gdbarch based on register values will be tricky. Possible, though. How do you detect, or plan to, when the register has changed? Poll it every time we stop the target? Once we know how to detect changes, that should let us determine when to select an appropriate architecture. I'd rather do it in some way that doesn't penalize debugging performance too badly for existing targets. Then there's the question of how to present this to the user. Maybe we only need to do it for some setting of "set mips abi". Anything else is going to involve changing the raw / ABI distinction that the port is currently designed around. -- Daniel Jacobowitz CodeSourcery