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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

The attached patch fixes a SEGV described in:

        http://sources.redhat.com/ml/gdb-patches/2004-07/msg00290.html

I followed Daniel's recommendation and made this change for all N32/N64
mips targets.

2004-07-22  Joel Brobecker  <brobecker@gnat.com>

        * mips-tdep.c (mips_gdbarch_init): Set size of long double
        to 128 bits for N32 and N64 ABIs.

Tested on mips-irix.

OK to commit?
-- 
Joel

[-- Attachment #2: mips-tdep.c.diff --]
[-- Type: text/plain, Size: 981 bytes --]

Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.301
diff -u -p -r1.301 mips-tdep.c
--- mips-tdep.c	10 Jul 2004 01:17:52 -0000	1.301
+++ mips-tdep.c	22 Jul 2004 15:37:12 -0000
@@ -5689,6 +5689,7 @@ mips_gdbarch_init (struct gdbarch_info i
       set_gdbarch_long_bit (gdbarch, 32);
       set_gdbarch_ptr_bit (gdbarch, 32);
       set_gdbarch_long_long_bit (gdbarch, 64);
+      set_gdbarch_long_double_bit (gdbarch, 128);
       break;
     case MIPS_ABI_N64:
       set_gdbarch_push_dummy_call (gdbarch, mips_n32n64_push_dummy_call);
@@ -5699,6 +5700,7 @@ mips_gdbarch_init (struct gdbarch_info i
       set_gdbarch_long_bit (gdbarch, 64);
       set_gdbarch_ptr_bit (gdbarch, 64);
       set_gdbarch_long_long_bit (gdbarch, 64);
+      set_gdbarch_long_double_bit (gdbarch, 128);
       break;
     default:
       internal_error (__FILE__, __LINE__, "unknown ABI in switch");

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

[Andrew Cagney]

Does long_double's floatformat need to be set?

> Index: mips-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mips-tdep.c,v
> retrieving revision 1.301
> diff -u -p -r1.301 mips-tdep.c
> --- mips-tdep.c	10 Jul 2004 01:17:52 -0000	1.301
> +++ mips-tdep.c	22 Jul 2004 15:37:12 -0000
> @@ -5689,6 +5689,7 @@ mips_gdbarch_init (struct gdbarch_info i
>        set_gdbarch_long_bit (gdbarch, 32);
>        set_gdbarch_ptr_bit (gdbarch, 32);
>        set_gdbarch_long_long_bit (gdbarch, 64);
> +      set_gdbarch_long_double_bit (gdbarch, 128);
>        break;
>      case MIPS_ABI_N64:
>        set_gdbarch_push_dummy_call (gdbarch, mips_n32n64_push_dummy_call);
> @@ -5699,6 +5700,7 @@ mips_gdbarch_init (struct gdbarch_info i
>        set_gdbarch_long_bit (gdbarch, 64);
>        set_gdbarch_ptr_bit (gdbarch, 64);
>        set_gdbarch_long_long_bit (gdbarch, 64);
> +      set_gdbarch_long_double_bit (gdbarch, 128);
>        break;
>      default:
>        internal_error (__FILE__, __LINE__, "unknown ABI in switch");

Andrew

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

[Joel Brobecker]

> Does long_double's floatformat need to be set?

Apparently not. Or I should say that I don't see any evidence that
it should.

-- 
Joel

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

[Andrew Cagney]

>>Does long_double's floatformat need to be set?
> 
> 
> Apparently not. Or I should say that I don't see any evidence that
> it should.

Check the floating-point tests in structs.exp and call-sc.exp.  There's 
hopefully also some sort of floating-point.exp test that confirms the 
basics.

Looking at the code, it appears to default to:

const struct floatformat *
default_double_format (struct gdbarch *gdbarch)
{
   int byte_order = gdbarch_byte_order (gdbarch);
   switch (byte_order)
     {
     case BFD_ENDIAN_BIG:
       return &floatformat_ieee_double_big;
     case BFD_ENDIAN_LITTLE:
       return &floatformat_ieee_double_little;
     default:
       internal_error (__FILE__, __LINE__,
                       "default_double_format: bad byte order");
     }
}

outch!

Andrew

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

[Joel Brobecker]

Hello Andrew,

On Tue, Jul 27, 2004 at 11:37:18AM -0400, Andrew Cagney wrote:
> >>Does long_double's floatformat need to be set?
> >
> >
> >Apparently not. Or I should say that I don't see any evidence that
> >it should.
> 
> Check the floating-point tests in structs.exp and call-sc.exp.  There's 
> hopefully also some sort of floating-point.exp test that confirms the 
> basics.
> 
> Looking at the code, it appears to default to:

You're right. The floatformat for long double on mips-irix right now
is the default floatformat_ieee_double_big. In pratice, I think this
is not so bad.

A collegue or mine kindly explained to me how the doubles pair work
to implement long doubles on IRIX. Basically, the high double holds
the result of the operation rounded to double, and the low double holds
the difference between the exact result and the rounded result. So
"high" + "low" holds the result with added precision, but "high"
contains the result rounded to double precision.

In terms of how this affects the debugger: GDB currently only uses
the high part of the long double, so it loses a bit of precision when
printing long doubles. I don't think this is a problem at all, since
we "only" print doubles with 17 digits. Similarly, I don't think we
lose much when we ask the debugger to change the value of a long double
variable, since I think a user will seldom provide a float with 50+
digits (If I had to do that, I would use the hex value, and write it
in memory directly).

Can we do better, and have a more accurate float format? It seems
to me that the answer would be: not with the current floatformat
description. Not a big deal, as far as I am concerned.

There is one little sticky point: When calling a procedure with a long
double as a parameter, GDB chokes:

        (gdb) call pd (a)
        That operation is not available on integers of more than 8 bytes.

This is an issue indeed, but I think it can be dealt with separately
of the patch I submitted.

Let me know what you think.

-- 
Joel

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

[Michael Chastain]

Joel Brobecker <brobecker@gnat.com> wrote:
> Let me know what you think.

I would suggest: take the explanation of "long double" on mips irix and
file it into a PR.  If you could write a ten-line program and include
the C source and the assembly output in the PR, then the whole schmeer
can be there in GNATS for the day when somebody says "I have some free
time, let's work on MIPS PR's".

Michael C

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

[Andrew Cagney]

> You're right. The floatformat for long double on mips-irix right now
> is the default floatformat_ieee_double_big. In pratice, I think this
> is not so bad.
> 
> A collegue or mine kindly explained to me how the doubles pair work
> to implement long doubles on IRIX. Basically, the high double holds
> the result of the operation rounded to double, and the low double holds
> the difference between the exact result and the rounded result. So
> "high" + "low" holds the result with added precision, but "high"
> contains the result rounded to double precision.

What happens little endian?

> In terms of how this affects the debugger: GDB currently only uses
> the high part of the long double, so it loses a bit of precision when
> printing long doubles. I don't think this is a problem at all, since
> we "only" print doubles with 17 digits. Similarly, I don't think we
> lose much when we ask the debugger to change the value of a long double
> variable, since I think a user will seldom provide a float with 50+
> digits (If I had to do that, I would use the hex value, and write it
> in memory directly).
> 
> Can we do better, and have a more accurate float format? It seems
> to me that the answer would be: not with the current floatformat
> description. Not a big deal, as far as I am concerned.

To back up a little.

Was the problem that GDB was dieing during a testsuite run, or that 
users were complaining "long double" didn't work on IRIX?  I'd suspect 
the former as, as far as I can tell, IRIX's long-double has always been 
broken.

If we do the above (I'm guessing that you're suggesting that long double 
format get explicitly set to ieee-double + a comment), then we get into 
the territory where GDB is lieing to the user - it appears to support 
something but doesn't.  I prefer to see us fix the problems, or at least 
make it clear to the user that the feature isn't supported.  While 
neither you nor I care about the last few bits of 128-bit 
floating-point, I can bet you that are fortran programmers that do :-/

We at least need to update http://sources.redhat/com/gdb/bugs/866
so we've more weight behind the argument that floatformat should be 
replaced (by GCC's code, hmm, does GCC's cross-platform floating-point 
library handle this?).

I also think that the architecture vector should stop supplying a 
default value for unknown float-formats -> here its clearly wrong and 
very hard to detect.

> There is one little sticky point: When calling a procedure with a long
> double as a parameter, GDB chokes:
> 
>         (gdb) call pd (a)
>         That operation is not available on integers of more than 8 bytes.
> 
> This is an issue indeed, but I think it can be dealt with separately
> of the patch I submitted.
> 
> Let me know what you think.

thoughts?
Andrew

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

[Joel Brobecker]

> >A collegue or mine kindly explained to me how the doubles pair work
> >to implement long doubles on IRIX. Basically, the high double holds
> >the result of the operation rounded to double, and the low double holds
> >the difference between the exact result and the rounded result. So
> >"high" + "low" holds the result with added precision, but "high"
> >contains the result rounded to double precision.
> 
> What happens little endian?

Unfortunately, I don't know how to answer that question. I am even
wondering whether it makes sense or not to ask it. I have searched
through all the IRIX documents I have here (mostly the N32 ABI handbook,
as well as the N32/N64 transition guide), and they don't even define
the format for "long doubles". All they say is that on N32 and N64,
long double = 128 bits. I am wondering if this aspect is not left
as a software convention, although that would seem a bit chancy to
me to rely on a simple software convention for base type
representations.

Anyway, I don't know :-(.

> Was the problem that GDB was dieing during a testsuite run, or that 
> users were complaining "long double" didn't work on IRIX?  I'd suspect 
> the former as, as far as I can tell, IRIX's long-double has always been 
> broken.

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).

> If we do the above (I'm guessing that you're suggesting that long double 
> format get explicitly set to ieee-double + a comment), then we get into 
> the territory where GDB is lieing to the user - it appears to support 
> something but doesn't.  I prefer to see us fix the problems, or at least 
> make it clear to the user that the feature isn't supported.  While 
> neither you nor I care about the last few bits of 128-bit 
> floating-point, I can bet you that are fortran programmers that do :-/

Then let's let the fortran developpers fix it :-).

I vote for setting the format to ieee-double with a comment.

> We at least need to update http://sources.redhat/com/gdb/bugs/866
> so we've more weight behind the argument that floatformat should be 
> replaced (by GCC's code, hmm, does GCC's cross-platform floating-point 
> library handle this?).

OK, I will add a blub about this in this PR.

> I also think that the architecture vector should stop supplying a 
> default value for unknown float-formats -> here its clearly wrong and 
> very hard to detect.

I am not sure I agree. I would think that, if the default float format
is not IEEE, then the debugger will print obviously incorrect values
most of the time. I think we shouldn't let the IRIX case drive the
decision, because it is using such a particular format (the feedback
I've heard about this format is not very positive). What I'm trying
to say is that, when doing a new port, chances are floats will either
be IEEE and the default should be fine, or output printed by GDB
will be obviously wrong because the mantissa size is different, or
something like that. But I have very little knowledge about floats
outside of IEEE, so it's not a firm opinion.

-- 
Joel

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

[Andrew Cagney]

>>>> >A collegue or mine kindly explained to me how the doubles pair work
>>>> >to implement long doubles on IRIX. Basically, the high double holds
>>>> >the result of the operation rounded to double, and the low double holds
>>>> >the difference between the exact result and the rounded result. So
>>>> >"high" + "low" holds the result with added precision, but "high"
>>>> >contains the result rounded to double precision.
>>
>>> 
>>> What happens little endian?
> 
> 
> Unfortunately, I don't know how to answer that question. I am even
> wondering whether it makes sense or not to ask it. I have searched
> through all the IRIX documents I have here (mostly the N32 ABI handbook,
> as well as the N32/N64 transition guide), and they don't even define
> the format for "long doubles". All they say is that on N32 and N64,
> long double = 128 bits. I am wondering if this aspect is not left
> as a software convention, although that would seem a bit chancy to
> me to rely on a simple software convention for base type
> representations.

Try the compiler to see if it can still generate LE code.  It might give 
a hint.

> Anyway, I don't know :-(.
> 
> 
>>> Was the problem that GDB was dieing during a testsuite run, or that 
>>> users were complaining "long double" didn't work on IRIX?  I'd suspect 
>>> the former as, as far as I can tell, IRIX's long-double has always been 
>>> broken.
> 
> 
> 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?

>>> If we do the above (I'm guessing that you're suggesting that long double 
>>> format get explicitly set to ieee-double + a comment), then we get into 
>>> the territory where GDB is lieing to the user - it appears to support 
>>> something but doesn't.  I prefer to see us fix the problems, or at least 
>>> make it clear to the user that the feature isn't supported.  While 
>>> neither you nor I care about the last few bits of 128-bit 
>>> floating-point, I can bet you that are fortran programmers that do :-/
> 
> 
> Then let's let the fortran developpers fix it :-).

Or the Ada developers :-)

> 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.

>>> We at least need to update http://sources.redhat/com/gdb/bugs/866
>>> so we've more weight behind the argument that floatformat should be 
>>> replaced (by GCC's code, hmm, does GCC's cross-platform floating-point 
>>> library handle this?).
> 
> 
> OK, I will add a blub about this in this PR.
> 
> 
>>> I also think that the architecture vector should stop supplying a 
>>> default value for unknown float-formats -> here its clearly wrong and 
>>> very hard to detect.
> 
> 
> I am not sure I agree. I would think that, if the default float format
> is not IEEE, then the debugger will print obviously incorrect values
> most of the time. I think we shouldn't let the IRIX case drive the
> decision, because it is using such a particular format (the feedback
> I've heard about this format is not very positive). What I'm trying
> to say is that, when doing a new port, chances are floats will either
> be IEEE and the default should be fine, or output printed by GDB
> will be obviously wrong because the mantissa size is different, or
> something like that. But I have very little knowledge about floats
> outside of IEEE, so it's not a firm opinion.

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 :-(

Andrew

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

[Michael Chastain]

Andrew Cagney writes:
ac> I prefer to see us fix the problems, or at least 
ac> make it clear to the user that the feature isn't supported.

Joel Brobecker writes:
joel> Then let's let the fortran developpers fix it :-).

I agree with Andrew here.  Let's not lie, even if we have to say
"irix_long_double : printf ("not supported\n")" with a big comment
about what we do know.

As far as "default_long_double : printf ("not supported\n")",
I actually like that too!

My two cents,

Michael C

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

[Joel Brobecker]

> 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

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

[Mark Kettenis]

   Date: Mon, 2 Aug 2004 21:39:06 -0700
   From: Joel Brobecker <brobecker@gnat.com>

   > >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 agree.

   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.

Folks, Please realize that in practice, printing an approximation is
the best we can do anyway.  Unless we've got a native GDB and we've
properly set the host's floatformat in configure.host.  And in that
case the actual description shouldn't really matter; just that it
matches the description of the target floatformat.  So ...

   > >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?).

.. this seems a perfectly acceptable solution to me.  It'd avoid us
to really lie about the floating-point format, even though we're not
telling the complete truth.

Mark

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

[Paul Koning]

>>>>> "Mark" == Mark Kettenis <kettenis@jive.nl> writes:

 >> 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.

 Mark> Folks, Please realize that in practice, printing an
 Mark> approximation is the best we can do anyway. 

I'm not sure the present case warrants the effort, but I don't think
that's true.  You could lift the gcc code in real.c, which has
conversions between target format and an oversized internal format.
With that you would be able to process 128 bit floats correctly on any
host.

Then again, I'm not sure why MIPS N32 is defined to have 128 bit
floats in the first place.  It seems rather silly considering that
there isn't any such data type in the machine instruction set.

      paul

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

[Alexandre Oliva]

On Aug  3, 2004, Paul Koning <pkoning@equallogic.com> wrote:

> Then again, I'm not sure why MIPS N32 is defined to have 128 bit
> floats in the first place.  It seems rather silly considering that
> there isn't any such data type in the machine instruction set.

The idea is of implementing long double as a pair of doubles is to
gain additional precision.  You can use the regular double floating
point instructions for all computations, and they can be implemented
somewhat efficiently.

This is the way IRIX does it; mips64-linux just uses standard IEEE
128-bit long doubles, so it has to be emulated.  That's mostly because
neither GCC nor glibc supported emulation with the IRIX format at the
time the port was written.  glibc still doesn't, AFAIK; GCC got
support for it, but IIRC it's darwin-specific.  AIX and Darwin also
use pairs of doubles as long doubles, but IIRC they have slightly
different conventions because AIX and IRIX disagree on the precision
they claim to support.

Hope this helps,

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

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

[Mark Kettenis]

   Date: Tue, 3 Aug 2004 09:31:35 -0400
   From: Paul Koning <pkoning@equallogic.com>

   >>>>> "Mark" == Mark Kettenis <kettenis@jive.nl> writes:

    >> 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.

    Mark> Folks, Please realize that in practice, printing an
    Mark> approximation is the best we can do anyway. 

   I'm not sure the present case warrants the effort, but I don't think
   that's true.  You could lift the gcc code in real.c, which has
   conversions between target format and an oversized internal format.
   With that you would be able to process 128 bit floats correctly on any
   host.

Ah, yes, of course.  What I meant to say is that with the current
state of affairs in GDB, that is, without some sort of floating-point
emulator, printing an approximation is the best we can do.

Mark