From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4292 invoked by alias); 10 Mar 2002 22:26:13 -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 4093 invoked from network); 10 Mar 2002 22:26:09 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 10 Mar 2002 22:26:09 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16kBlZ-0002bR-00; Sun, 10 Mar 2002 17:26:09 -0500 Date: Sun, 10 Mar 2002 14:26:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Don Howard , gdb-patches@sources.redhat.com Subject: Re: [RFA] mips: Fix "info registers" output Message-ID: <20020310172609.B9299@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Don Howard , gdb-patches@sources.redhat.com References: <20010619225007.A10141@nevyn.them.org> <20020307165956.A22042@nevyn.them.org> <3C8ABF59.7080908@cygnus.com> <20020310015637.A13373@nevyn.them.org> <3C8B8A11.8070609@cygnus.com> <20020310120037.A29124@nevyn.them.org> <3C8B9C06.9020506@cygnus.com> <20020310143027.A3933@nevyn.them.org> <3C8BC5DB.3040102@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C8BC5DB.3040102@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00149.txt.bz2 On Sun, Mar 10, 2002 at 03:45:15PM -0500, Andrew Cagney wrote: > >That wouldn't affect builtin_type_double, though, which we define in > >terms of the 64 bits. Are you saying that should be updated based on > >the type of 'double' in the objfile? I don't really think so, since > >'the type associated with the word "double"' isn't necessarily tied to > >"what this architecture would normally call a double" and > >builtin_type_double is the latter. MIPS would normally call a 64-bit > >FP quantity a double, whatever GCC is up to. > > Now I'm confused :-). The type builtin_type_double is determined by the > ABI, its value/behavour is influenced by TARGET_DOUBLE_BIT, > TARGET_BYTE_ORDER and TARGET_DOUBLE_FORMAT. They are all attributes of > the ABI and their values can be determined from the object file. OK... but in all MIPS ABIs that I'm aware of, ever, double is 64-bit. Still, I see that I've misunderstood the meaning of the builtin types. > Separate to this is the real register format and that is determined by > the ISA. > > Consider the PPC which has strictly 64 bit FP registers but supports the > 32 bit ``float'' type. If you print the register it is 64 bit, if you > print a 32 bit float stored in the register than the 64 bit value is > first converted to 32 bit. > > Other examples are Arm, m68k and i386. As soon as those targets stopped > trying to use type_double et.al. bugs mysteriously disappeared and the > code became simpler :-) The mips hasn't yet done this. > > > > >Right; the way registers are acquired is both ISA and ABI dependent. I > >don't know that the way they are interpreted afterwards is ABI > >dependent... > > Their interpretation is ISA dependant so they should be using things > like type_ieee_double et.al. Right now, for MIPS, builtin_type_double always means "whichever of builtin_type_ieee_double_{big,little} is appropriate" and likewise for builtin_type_float. (I note in passing that the type_ieee variables are not referenced. Anywhere. Only the floatformats are.) All I could see changed in mips-tdep.c would be to explicitly state that, and I don't really see the point, given the MIPS FP models we support. That's why I didn't see the need for the FIXME in question. Perhaps I'm not understanding you...? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer