From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29099 invoked by alias); 16 May 2003 22:50:16 -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 28976 invoked from network); 16 May 2003 22:50:14 -0000 Received: from unknown (HELO mms2.broadcom.com) (63.70.210.59) by sources.redhat.com with SMTP; 16 May 2003 22:50:14 -0000 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Fri, 16 May 2003 15:46:59 -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 PAA26081; Fri, 16 May 2003 15:49:48 -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 h4GMo8ov028641; Fri, 16 May 2003 15:50:08 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id PAA00842; Fri, 16 May 2003 15:50:07 -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:50:00 -0000 In-Reply-To: cgd@broadcom.com's message of "Fri, 16 May 2003 22:25:13 +0000 (UTC)" Message-ID: MIME-Version: 1.0 X-WSS-ID: 12DBB5E9291437-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00292.txt.bz2 At Fri, 16 May 2003 22:25:13 +0000 (UTC), cgd@broadcom.com wrote: > 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. Actually, on the reads they say that the values produced are unpredictable. For writes, they indicate that the operation itself is unpredictable ("UNPREDICTABLE"). in other words, doing an ldc1 when FR == 0 could cause a trap if an implementation were paranoid (*cough* simulator 8-). So, really, when FR == 0, best to think of yourself as having only 32 * 32 bits. Now, the question is, in the remote protocol, if 64-bit registers are being passed, *how*. (64-bit target, normally 64-bit registers... i'd assume they're being passed as 64-bits.) One reasonable way to do it, which i believe would be the result of using n32 / n64 RDA on linux to debug an o32 executable, would be: 0: meaningful 1: garbage etc. this is the natural way to do it on a 64-bit part, with a 64-bit FPU. another reasonable way (but less efficient on a 64-bit part with a 64-bit FPU) would be: 0: 1: Are there 64-bit parts out there that have FPUs with 32 single float regs which one can operate on (4650, looking at gcc srcs?) If so, the latter would be a reasonable representation for them. So, my conclusion is: for raw registers that are xferred as 64-bits, yeah, fine, let people have acess to them. that's for debugger-debugging, and people who muck with them may be shooting themselves in the head, but if they're debugging the debugger they're smart, right? 8-) need to have some way to tell which of the ways above is being used to xfer the register data. (or, need to define that only one way may be used.) chris