From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4991 invoked by alias); 19 Dec 2007 17:08:21 -0000 Received: (qmail 4977 invoked by uid 22791); 19 Dec 2007 17:08:19 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Dec 2007 17:07:54 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1J52Oc-000798-00; Wed, 19 Dec 2007 17:07:50 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1J52OV-0001uq-00; Wed, 19 Dec 2007 17:07:43 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1J52OU-0002Jf-VT; Wed, 19 Dec 2007 17:07:42 +0000 Date: Wed, 19 Dec 2007 17:15:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, Nigel Stephens , David Ung , "Maciej W. Rozycki" Subject: Re: mips-tdep.c: Unification of FPR size detection In-Reply-To: <20071216212504.GK22905@caradoc.them.org> Message-ID: References: <20071216212504.GK22905@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com 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/msg00322.txt.bz2 On Sun, 16 Dec 2007, Daniel Jacobowitz wrote: > I'll take your word for this part... I find the various FP modes confusing. Well, no surprise here and the addition of the 64-bit mode to MIPS32r2 has not made the view any clearer... > 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. Actually my long-term idea was to read the register when available and cache the value of the flag in the target code for cases when it is not accessible through the regular register cache. > 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. With the bit set all the FPU registers fp0 through to fp31 are 64-bit wide. All the double FP operations are performed on single registers. All the single FP operations are performed on single registers. With the bit clear all the FPU registers fp0 through to fp31 are 32-bit wide. All the double FP operations are performed on consecutive odd/even pairs of registers. All the single FP operations are performed on single registers. Note that there is a difference here between MIPS Architecture and legacy MIPS processors. For the formers all the registers may be used in this mode with single FP operations. For the latters only even-numbered registers are permitted. > 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? It is the raw hardware register size and as explained above we do want to check mips2_fp_compat(). I have a patch in the queue that makes cooked FP registers always be 64-bit though. > 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. There may be no ABI. GDB may just be connected to a running target, through EJTAG for example, with no executable selected. In this case the only source of information of the FPU configuration is hardware. I used it this way in the past. And in particular, when debugging the Linux kernel, it may change the setting of cp0.Status.FR under your feet, so whenever execution stops, the width of the FP register stack has to be updated following the state of the bit. Maciej