From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11772 invoked by alias); 16 Dec 2007 21:25:17 -0000 Received: (qmail 11624 invoked by uid 22791); 16 Dec 2007 21:25:15 -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; Sun, 16 Dec 2007 21:25:07 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id BC1AC98129; Sun, 16 Dec 2007 21:25:05 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 4D5C29811F; Sun, 16 Dec 2007 21:25:05 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J40yu-0000gB-LV; Sun, 16 Dec 2007 16:25:04 -0500 Date: Sun, 16 Dec 2007 21:26: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: <20071216212504.GK22905@caradoc.them.org> Mail-Followup-To: "Maciej W. Rozycki" , gdb-patches@sourceware.org, Nigel Stephens , David Ung , "Maciej W. Rozycki" References: 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/msg00226.txt.bz2 On Wed, Nov 21, 2007 at 05:40:28PM +0000, Maciej W. Rozycki wrote: > I think the changes are mostly obvious. If not, then please enquire. > Modifications to mips_o32_return_value(), mips_o32_push_dummy_call() and > mips_register_type() change the semantics somewhat, but this is correct as > for 64-bit processors in the compatibility mode FPRs are seen as 32-bit. > The rest just shuffles code for consistency. I'll take your word for this part... I find the various FP modes confusing. > One note: the mips2_fp_compat() function is meant to detect the size of > floating point registers based on the setting of the cp0.Status.FR bit as > applicable. However the function currently always returns 0. So I > decided to include a change that ifdefs out the entire body. Enabling the > body does not trigger any new regressions. I also added a note on a > problem with the frame being NULL -- it may have to be dealt with in a > better way once this code is reenabled. A possible way is by caching the > value of cp0.Status.FR elsewhere. 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. 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. So, which is mips_float_regsize supposed to be? The hardware register size, in which case it should not call mips2_fp_compat, or the software register size? Maybe we should rip mips2_fp_compat out entirely. We'd need yet a third layer of registers since we already have one for the ABI. -- Daniel Jacobowitz CodeSourcery