From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 890 invoked by alias); 16 May 2003 22:25:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 812 invoked from network); 16 May 2003 22:25:02 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sources.redhat.com with SMTP; 16 May 2003 22:25:02 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Fri, 16 May 2003 15:24:50 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA21729; Fri, 16 May 2003 15:24:36 -0700 (PDT) Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id h4GMOuov027990; Fri, 16 May 2003 15:24:56 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id PAA00797; Fri, 16 May 2003 15:24:55 -0700 (PDT) To: ac131313@redhat.com cc: "Kevin Buettner" , gdb-patches@sources.redhat.com Subject: Re: [WIP/RFC] MIPS registers overhaul References: <1030510002453.ZM3880@localhost.localdomain> <3EBD6131.30209@redhat.com> <1030514220025.ZM10373@localhost.localdomain> <3EC461C1.1080104@redhat.com> From: cgd@broadcom.com Date: Fri, 16 May 2003 22:25:00 -0000 In-Reply-To: ac131313@redhat.com's message of "Fri, 16 May 2003 04:00:14 +0000 (UTC)" Message-ID: MIME-Version: 1.0 X-WSS-ID: 12DBBAB85300124-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00291.txt.bz2 At Fri, 16 May 2003 04:00:14 +0000 (UTC), "Andrew Cagney" wrote: > > Whatever we call them, I think it's still useful to have names > > associated with them. E.g, you can do any of the following: > > > > print $raw_f20 > > print/x ($raw_f20 >> 32) > > set $raw_f20=0xbadbeef > > But how often will that actually happen? > > I think a user debugging o32 on ISA64 still should expect to be > manipulating the full 64 bit register. Only on ISA32 should the > registers be restricted to their 32 bit values. > > Even if the upper 32 bits of the FP registers are unpredictable, I think > they should still be displayed. I assume you're talking about manipulating the full 64-bits *only* for the raw values. I think there may be issues there, when FR == 0. When FR == 0, reading and writing doubles from the odd registers in unpredictable, and reading/writing doubles from the even registers ** must ** include the odd-register value. So, for instance, when FR = 0, if you read 64 bits of $f12, you'll get: $f12: 0xaaaaaaaabbbbbbbb That's guarateed. if you read a single from $f12, you'll get 0xbbbbbbbb, a single from $f13 you'll get 0xaaaaaaaa. Likewise, guaranteed. but if you read a double from $f13, who *knows* what you're going to get. You might get: $f13: 0x????????aaaaaaaa but who really knows, and who knows what the ???????? is. (I think i got my word ordering right in that description. 8-) When FR==0, there are only two valid ways to read the registers: * for i = 0; i < 32; i++ * for i = 0; i < 32; i += 2 This MIPS specifications (M64 1.00 Volume I, page 50, section 5.6.2) indicate that doing 64-bit reads/writes from/to odd FP registers when FR=0 are "illegal", and that values produced by such operations are unpredictable. In other words, if a 64-bit target stub code really is supplying 64 bits of register data when accessing FP registers when FR == 0, then it's broken. (If it's attempting to write the odd 64-bit register values back, then it's *really* broken.) Heck, if 64-bit target code is even trying to communicate (64 * 8) bits back when FR == 0, then it's almost certainly broken. (every other reigster will be completely unpredictable, and who knows what'll happen if it tries to write them back if they're changed.) As an aside, it would probably be good if, when setting a fp register, e.g.: set $f12 = you were *required* to use one of the union members. it's kinda weird (uh, quite confusing 8-) to see something like: (gdb) info args a = -nan(0x7fffff) b = 2.20000005 c = 3.29999995 d = -4.4000001 (gdb) info addr b Symbol "b" is an argument in register f13. (gdb) set $f13 = 3.3 (gdb) info args a = -nan(0x7fffff) b = 2.72008302e+23 c = 3.29999995 d = -4.4000001 i.e., blind conversion (because "set $f13 = " assumed incorrectly that you meant "oh, as double") is bad. (If you're in the situation where you're setting an even register to a single value, if the n+1 odd reigster also a single value you also want to do computation on, setting the even as a double could be even worse...) cgd