From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21354 invoked by alias); 16 Jun 2003 20:41:44 -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 21216 invoked from network); 16 Jun 2003 20:41:43 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 16 Jun 2003 20:41:43 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4DC5D2B5F; Mon, 16 Jun 2003 16:41:41 -0400 (EDT) Message-ID: <3EEE2B85.6030207@redhat.com> Date: Mon, 16 Jun 2003 20:41: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 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> <3ECA8EC6.6030405@redhat.com> <3EECAB89.10609@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00547.txt.bz2 >> OK, I'm going to go out on a limb here. I don't think the two are >> equivalent, and I think the second is wrong. For big-endian, the >> second would store fp[n+0] ||| fp[n+1] backwards. > > > No, the two are not equivalent, in terms of the memory layout that > results on big endian systems. (On little-endian systems, AFAICT they > end up producing the same results.) > > However, neither is more correct w.r.t. what's allowed by the MIPS > architecture; both will work with MIPS2 and later hardware. Doing the > stores as dwords is clearly more efficient, though. The IRIX kernel exports an interface that makes it appear as though two single stores were used. To GDB, that interface is all that matters :-) > Err, I'm not sure what code you reference. I couldn't find > "register_to_type" (case insensitively), anywhere in the GDB source. Sorry, it was register_to_type. It's been replaced with register_to_value. > is going to need, for BE, a big-byte little-word DOUBLE, and a similar >> INT64. Otherwize, $f0.int32 would modify the wrong part of the double >> register. Alternatively, some of those union values could be given >> magic offsets. Looking at kevin's patch: > > > Right. I think the "assume 4 bytes of pad before the 4-byte item" is > the right way to look at it. The kernel, when it presents the value to GDB, doesn't do that. It puts the even register in the low address. If possible the register's type should reflect the underlying format - big-byte, little-word. > And then to follow on from that: > > * if 32-bit FPU (32-bit MIPS or 64-bit MIPS with FR == 0), assume you > have 16 of them, or Careful. If the ABI is o32, and FR == 0/..., then there should be only 16 floating point registers in use. The original MIPS 1, and r5900 ABIs would both allow use of all 32 32 bit floating point registers. > * if 64-bit FPU, you have 32. > > (at least, that's the way it should work for "normal" FPU usage. For > single-float, where $f0 and $f1 contain independent singles, it's > another story.) Yes. Andrew