From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16762 invoked by alias); 20 May 2003 20:25:22 -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 13138 invoked from network); 20 May 2003 20:23:41 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 20 May 2003 20:23:41 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 446A72B2F; Tue, 20 May 2003 16:23:34 -0400 (EDT) Message-ID: <3ECA8EC6.6030405@redhat.com> Date: Tue, 20 May 2003 20:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cgd@broadcom.com, Kevin Buettner Cc: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00368.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"). When a 64 bit kernel goes to save/resume an o32 process, how does it do it? Does it have a choice? For instance, do a 64 bit FP restore then clear the FR bit; the reverse; some other variant; ...? Andrew > 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 > >