From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7345 invoked by alias); 19 Dec 2007 17:15:41 -0000 Received: (qmail 7334 invoked by uid 22791); 19 Dec 2007 17:15:41 -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; Wed, 19 Dec 2007 17:15:33 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 928C998151; Wed, 19 Dec 2007 17:15:31 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 532FA9814F; Wed, 19 Dec 2007 17:15:31 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J52W2-0001Je-FU; Wed, 19 Dec 2007 12:15:30 -0500 Date: Wed, 19 Dec 2007 20:55: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: <20071219171530.GA4896@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> 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/msg00323.txt.bz2 On Wed, Dec 19, 2007 at 05:07:42PM +0000, Maciej W. Rozycki wrote: > > This part does not make sense to me and it suggests that the patch is > > wrong. In general, if you have a function that wants something to do > > with a frame and there isn't a frame available you have a design > > problem. > > Well, I do not insist on getting through to the cp0.Status register > through the frame. It is just that with the recent removal of the > globally accessible "current_regcache" variable, you cannot get at the > register file otherwise than through the frame. I am looking forward to > suggestions as to how to access the register bypassing the frame > infrastructure. No, that's the exact opposite of what I meant. If you don't have a frame available, then you have to assume the target essentially has no registers (yet, or any longer, or...). So we can not make any decisions based on their values. If you're caching the value, it seems suspiciously to me like guessing an arbitrary wrong value, maybe even from a previous session. > > The target's registers are a certain size. That's independent of the > > FR bit, which should affect only what we put into the registers and > > how we interpret the results. We can not change the type of registers > > during execution; the regcache caches the types and sizes. Anything > > dependent on the FR bit can change during execution, so it can not be > > a property of the gdbarch (which the return value of > > mips_register_type is). It should be possible to make the types of > > the pseudo-register view change based on FR, though it might upset > > other bits of GDB; I'm not sure without trying it. But the raw > > register has to stay fixed. > > That is actually incorrect. We do not have to know how it is implemented > internally in a given CPU and I am told it may indeed vary, but in > principle cp0.Status.FR does actually change the width of raw floating > point registers. 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? Something needs to change, sure, but I don't think this is it. -- Daniel Jacobowitz CodeSourcery