Re: [RFA/mips] 128-bit long doubles for N32/N64

[Joel Brobecker <brobecker@gnat.com>]

> 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