From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17989 invoked by alias); 20 Dec 2007 16:57:33 -0000 Received: (qmail 17981 invoked by uid 22791); 20 Dec 2007 16:57:32 -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; Thu, 20 Dec 2007 16:57:24 +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 1J5Oi0-0005XC-00; Thu, 20 Dec 2007 16:57:20 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1J5Ohr-0000qg-00; Thu, 20 Dec 2007 16:57:11 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1J5Ohr-0002St-S1; Thu, 20 Dec 2007 16:57:11 +0000 Date: Thu, 20 Dec 2007 16:58: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: <20071219171530.GA4896@caradoc.them.org> Message-ID: References: <20071216212504.GK22905@caradoc.them.org> <20071219171530.GA4896@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/msg00345.txt.bz2 On Wed, 19 Dec 2007, Daniel Jacobowitz wrote: > 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. Well, for whatever reason a frame is commonly not available during a debugging session -- I think it gets invalidated at some point and the problem is in the process of being reestablished the size of the FP registers is being determined. I can see if I can get a backtrace leading to this scenario. 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. > 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. It is misleading for current (MIPS rev.2) processors though as in the 32-bit FPR mode all the registers are full-featured single FPRs and also the paired-single and fixed long type are not supported with pairs of registers even though the double type is. I am not sure that pretending the architecture of the FPU is different to what it actually is is going to gain us anything. > Something needs to change, sure, but I don't think this is it. Any proposals then? Either way cp0.Status.FR has to be checked -- either for the width of FPRs (64-bit vs 32-bit) as in the patch proposed or for the number of them (32 vs 16) if the width is pretended to be always 64-bit. Maciej