From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13160 invoked by alias); 3 Aug 2004 04:39:11 -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 13136 invoked from network); 3 Aug 2004 04:39:07 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 3 Aug 2004 04:39:07 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id BD88447D91; Mon, 2 Aug 2004 21:39:06 -0700 (PDT) Date: Tue, 03 Aug 2004 04:39:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/mips] 128-bit long doubles for N32/N64 Message-ID: <20040803043906.GZ32638@gnat.com> References: <20040722154456.GG1289@gnat.com> <41058380.6050407@gnu.org> <20040726224546.GB20596@gnat.com> <410676AE.4010001@gnu.org> <20040802011520.GA32638@gnat.com> <410E886E.1060702@gnu.org> <20040803011338.GY32638@gnat.com> <410EF168.3040304@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410EF168.3040304@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-08/txt/msg00062.txt.bz2 > Try the compiler to see if it can still generate LE code. It might give > a hint. I can try the experiment, but you'll have to tell me how to generate the LE code (I use GCC). > >It was a crash. With the change I'm suggesting, we're fixing the crash, > >and also printing/setting the value of long double variables with the > >same precision as doubles (ie we ignore the low half of the long double). > > So we need to fix this - no long double shouldn't crash GDB (internal > error well ok but not crash). Can you dig up the details? This is exactly what my patch is about. I'll quote my initial report: The problem is that GDB thinks that long double variables are 64 bits long, but they are in fact 128 bits long. The discrepancy causes GDB to fail to find the associated format for type doublest (which is a typedef of long double), and then call floatformat_is_valid() with a NULL format... Basically, GDB knows the size of each float format via the gdbarch_set_* routines and the defaults. From there, it builds a list of floatformats which it searches when it needs to print a float of a given size. In my testcase, we tried to print a 128bit float, but the largest size in our list of floatformats was 64. So we ended up with a null floatformat and kaboum. My patch aims at fixing the kaboum. > >Then let's let the fortran developpers fix it :-). > > Or the Ada developers :-) Honestly, I think we're letting the best be the enemy of good. We have the choice between printing an approximation of a float, or printing nothing at all. Some users will be satisfied with the approximation. I will be. Why penalize these users? I am ok with documenting this approximation in the GDB manual. If whoever wants to fix this later, then fine. But in the meantime, I think something is better than nothing. I am also wondering if this whole discussion will affect my patch at all. In the end, long doubles will still be 128 bits long, right? So whatever we decide on this issue, we'll still have to set that part of the gdbarch vector. Right? > >I vote for setting the format to ieee-double with a comment. > > That would also be wrong. > > Closer would be a new 128bit irix floatformat that knew how to unpack > the first 64-bits. Indeed, maybe it would be cleaner to create a new irix-specific 128bit floatformat that only uses the bits in the high part (basically, it would be a copy of the ieee_big with the size set to 128bits, or something like that, right?). > To speak from experience, the first users of a new port care little for > floating point, they are too busy reporting bugs in the backtrace and > single-step code to care much about anything else. Only once the > debugger is thought to be mature do people start to notice that the > floating-point code has been wrong for years :-( > > Here, this never worked. The only reason we noticed is, I think, > because tests were added to [indirectly] test it. When I rewrote > structs.exp I noticed comments saying don't test long double, it doesn't > work :-( I don't have a strong preference on this issue. So I have no problem with removing the defaults. But be careful to add some guards everywhere we lookup floatformats, because GDB will crash when it can not find a floatformat for a given size. And we'll also need to update all the targets that take advantage of this default. -- Joel