[RFC] Detecting and printing 128-bit long double values for PPC

[RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

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

Hi,

Follows attached the patch for detecting and printing 128-bit long
double values on GDB for PPC. 

This patch was originally written by Pete Carr some time ago. Since its
discussion didn't go much further, i've refreshed it to cleanly apply on
HEAD. The original message with the patch can be found here:
(http://sourceware.org/ml/gdb-patches/2006-07/msg00098.html)

I've modified some bits and pieces suggested by  Mark Kettenis and
Daniel Jacobowitz on these mailing list entries.

http://sourceware.org/ml/gdb-patches/2006-07/msg00103.html
http://sourceware.org/ml/gdb-patches/2006-07/msg00107.html


Comments are welcome.

Best regards,
Luis

[-- Attachment #2: long_double.diff --]
[-- Type: text/x-patch, Size: 6437 bytes --]

2007-04-26  Pete Carr  <pecarr@us.ibm.com>
						Luis Machado  <luisgpm@br.ibm.com>

	* rs6000-tdep.c (rs6000_gdbarch_init): Set the long double format for
	powerpc64.
	* configure.host : Set the host long double format for powerpc64 to be
	a 128-bit type defined in libiberty/floatformat.c.
	* ppc-linux-tdep.c (ppc_linux_init_abi): Remove code that sets long double 
	size to 8 bytes.
	* floatformat.c : Introduce default floatformat structs to describe the
	128-bit long double found on the powerpc64. Description does not fully
	describe this format which is actually a pair of 64-bit doubles. However
	we are relying on floatformat_to_doublest() recognizing that this is
	also the default host floatformat.
	* floatformat.h : Default floatformat structs for powerpc64 128-bit
	long doubles.
	* gdbtypes.h : Added new type struct floatformats_ppc64_long_double 
	declaration
	* gdbtypes.c : Added new type struct floatformats_ppc64_long_double

Index: gdb/configure.host
===================================================================
--- gdb/configure.host.orig	2007-04-27 21:05:28.000000000 -0700
+++ gdb/configure.host	2007-04-27 21:05:32.000000000 -0700
@@ -198,6 +198,11 @@
 	gdb_host_double_format="&floatformat_ieee_double_big"
 	gdb_host_long_double_format="&floatformat_m68881_ext"
 	;;
+powerpc64-*-*)
+	gdb_host_float_format=0
+	gdb_host_double_format=0
+	gdb_host_long_double_format="&floatformat_ppc64_long_double_big"
+	;;
 *)
 	gdb_host_float_format=0
 	gdb_host_double_format=0
Index: gdb/ppc-linux-tdep.c
===================================================================
--- gdb/ppc-linux-tdep.c.orig	2007-04-27 21:05:28.000000000 -0700
+++ gdb/ppc-linux-tdep.c	2007-04-27 21:12:29.000000000 -0700
@@ -1028,16 +1028,6 @@
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
-  /* NOTE: jimb/2004-03-26: The System V ABI PowerPC Processor
-     Supplement says that long doubles are sixteen bytes long.
-     However, as one of the known warts of its ABI, PPC GNU/Linux uses
-     eight-byte long doubles.  GCC only recently got 128-bit long
-     double support on PPC, so it may be changing soon.  The
-     Linux[sic] Standards Base says that programs that use 'long
-     double' on PPC GNU/Linux are non-conformant.  */
-  /* NOTE: cagney/2005-01-25: True for both 32- and 64-bit.  */
-  set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
-
   if (tdep->wordsize == 4)
     {
       /* Until November 2001, gcc did not comply with the 32 bit SysV
Index: gdb/rs6000-tdep.c
===================================================================
--- gdb/rs6000-tdep.c.orig	2007-04-27 21:05:28.000000000 -0700
+++ gdb/rs6000-tdep.c	2007-04-27 21:05:32.000000000 -0700
@@ -3425,7 +3425,13 @@
   set_gdbarch_float_bit (gdbarch, 4 * TARGET_CHAR_BIT);
   set_gdbarch_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
   if (sysv_abi)
-    set_gdbarch_long_double_bit (gdbarch, 16 * TARGET_CHAR_BIT);
+    {
+      int byte_order = gdbarch_byte_order (gdbarch);
+
+      set_gdbarch_long_double_format(gdbarch, floatformats_ppc64_long_double);
+      
+      set_gdbarch_long_double_bit (gdbarch, 16 * TARGET_CHAR_BIT);
+    }
   else
     set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT);
   set_gdbarch_char_signed (gdbarch, 0);
Index: include/floatformat.h
===================================================================
--- include/floatformat.h.orig	2007-04-27 21:05:28.000000000 -0700
+++ include/floatformat.h	2007-04-27 21:05:32.000000000 -0700
@@ -118,6 +118,9 @@
 extern const struct floatformat floatformat_ia64_spill_little;
 extern const struct floatformat floatformat_ia64_quad_big;
 extern const struct floatformat floatformat_ia64_quad_little;
+/* ppc64 long double implemented as 2 doubles */
+extern const struct floatformat floatformat_ppc64_long_double_big;
+extern const struct floatformat floatformat_ppc64_long_double_little;
 
 /* Convert from FMT to a double.
    FROM is the address of the extended float.
Index: libiberty/floatformat.c
===================================================================
--- libiberty/floatformat.c.orig	2007-04-27 21:05:28.000000000 -0700
+++ libiberty/floatformat.c	2007-04-27 21:05:32.000000000 -0700
@@ -106,6 +106,25 @@
   floatformat_always_valid
 };
 
+/* floatformats for ppc64 long double, big and little endian.
+		The layout is a pair of doubles. Don't use this description to pass
+		information to get_field(). The bit size is the important thing. */
+const struct floatformat floatformat_ppc64_long_double_big =
+{
+  floatformat_big, 128, 0, 1, 11, 1023, 2047, 12, 52, 
+  floatformat_intbit_no,
+  "floatformat_ppc64_long_double_big",
+  floatformat_always_valid
+};
+
+const struct floatformat floatformat_ppc64_long_double_little =
+{
+  floatformat_little, 128, 0, 1, 11, 1023, 2047, 12, 52, 
+  floatformat_intbit_no,
+  "floatformat_ppc64_long_double_little",
+  floatformat_always_valid
+};
+
 /* floatformat for IEEE double, little endian byte order, with big endian word
    ordering, as on the ARM.  */
 
Index: gdb/gdbtypes.c
===================================================================
--- gdb/gdbtypes.c.orig	2007-04-27 21:05:28.000000000 -0700
+++ gdb/gdbtypes.c	2007-04-27 21:06:00.000000000 -0700
@@ -112,6 +112,11 @@
   &floatformat_ieee_double_big,
   &floatformat_ieee_double_littlebyte_bigword
 };
+const struct floatformat *floatformats_ppc64_long_double[BFD_ENDIAN_UNKNOWN] =
+{
+  &floatformat_ppc64_long_double_big,
+  &floatformat_ppc64_long_double_little
+};
 const struct floatformat *floatformats_i387_ext[BFD_ENDIAN_UNKNOWN] = {
   &floatformat_i387_ext,
   &floatformat_i387_ext
Index: gdb/gdbtypes.h
===================================================================
--- gdb/gdbtypes.h.orig	2007-04-27 21:05:28.000000000 -0700
+++ gdb/gdbtypes.h	2007-04-27 21:05:32.000000000 -0700
@@ -1118,6 +1118,7 @@
 extern const struct floatformat *floatformats_ieee_single[BFD_ENDIAN_UNKNOWN];
 extern const struct floatformat *floatformats_ieee_double[BFD_ENDIAN_UNKNOWN];
 extern const struct floatformat *floatformats_ieee_double_littlebyte_bigword[BFD_ENDIAN_UNKNOWN];
+extern const struct floatformat *floatformats_ppc64_long_double[BFD_ENDIAN_UNKNOWN];
 extern const struct floatformat *floatformats_i387_ext[BFD_ENDIAN_UNKNOWN];
 extern const struct floatformat *floatformats_m68881_ext[BFD_ENDIAN_UNKNOWN];
 extern const struct floatformat *floatformats_arm_ext[BFD_ENDIAN_UNKNOWN];

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Daniel Jacobowitz]

On Sat, Apr 28, 2007 at 02:38:24AM -0300, Luis Machado wrote:
> Hi,
> 
> Follows attached the patch for detecting and printing 128-bit long
> double values on GDB for PPC. 
> 
> This patch was originally written by Pete Carr some time ago. Since its
> discussion didn't go much further, i've refreshed it to cleanly apply on
> HEAD. The original message with the patch can be found here:
> (http://sourceware.org/ml/gdb-patches/2006-07/msg00098.html)
> 
> I've modified some bits and pieces suggested by  Mark Kettenis and
> Daniel Jacobowitz on these mailing list entries.
> 
> http://sourceware.org/ml/gdb-patches/2006-07/msg00103.html
> http://sourceware.org/ml/gdb-patches/2006-07/msg00107.html

Unfortunately most of Mark's comments are still unaddressed.  The
formatting doesn't follow the GNU coding standards, and the real
issue with this patch is that there are a lot of systems out in the
world that use 64-bit long double still.

I mentioned last week on gdb@ and binutils@ that I think we need a way
to mark the ABI used by PowerPC binaries.  That would easily cover
this also.  I'll be thinking about it more next week.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Ulrich Weigand]

Daniel Jacobowitz wrote:

> Unfortunately most of Mark's comments are still unaddressed.  The
> formatting doesn't follow the GNU coding standards, and the real
> issue with this patch is that there are a lot of systems out in the
> world that use 64-bit long double still.
> 
> I mentioned last week on gdb@ and binutils@ that I think we need a way
> to mark the ABI used by PowerPC binaries.  That would easily cover
> this also.  I'll be thinking about it more next week.

We have the same situation on s390, where we switched from 64-bit to
128-bit long double a while ago.  Like PowerPC, there is currently no
way to recognize how a binary was built ...

While an ABI marker might be a good idea in the future, we're stuck
with the situation right now that many unmarked 128-bit long double
binaries are already out there (e.g. all of SLES 10 and RHEL 5),
and we really should be able to debug those properly.

Thus I'm wondering whether we shouldn't have a reasonable default
for unmarked binaries, presumably based on the system compiler
defaults detected at configure time for native builds, and then
provide a command allowing the user to override that default?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Daniel Jacobowitz]

On Sat, Apr 28, 2007 at 06:24:14PM +0200, Ulrich Weigand wrote:
> We have the same situation on s390, where we switched from 64-bit to
> 128-bit long double a while ago.  Like PowerPC, there is currently no
> way to recognize how a binary was built ...
> 
> While an ABI marker might be a good idea in the future, we're stuck
> with the situation right now that many unmarked 128-bit long double
> binaries are already out there (e.g. all of SLES 10 and RHEL 5),
> and we really should be able to debug those properly.
> 
> Thus I'm wondering whether we shouldn't have a reasonable default
> for unmarked binaries, presumably based on the system compiler
> defaults detected at configure time for native builds, and then
> provide a command allowing the user to override that default?

Well, that's pretty much what I did for our customer who reported the
equivalent problem with PowerPC -msoft-float; except instead of
detecting it at configure time I added a manual configure option
(since this was for a cross-debugger).

But it doesn't really scale... I'm open to better ideas...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

Isn't GDB currently able to detect the type length in runtime in order
to correctly print those values?

With this modification i've noticed that GDB cuts the extra precision
bytes for a binary built with -mlong-double-64, while printing the value
with the total avaiable precision when it's built with
-mlong-double-128.

Regards,
Luis

On Sat, 2007-04-28 at 12:27 -0400, Daniel Jacobowitz wrote:
> On Sat, Apr 28, 2007 at 06:24:14PM +0200, Ulrich Weigand wrote:
> > We have the same situation on s390, where we switched from 64-bit to
> > 128-bit long double a while ago.  Like PowerPC, there is currently no
> > way to recognize how a binary was built ...
> > 
> > While an ABI marker might be a good idea in the future, we're stuck
> > with the situation right now that many unmarked 128-bit long double
> > binaries are already out there (e.g. all of SLES 10 and RHEL 5),
> > and we really should be able to debug those properly.
> > 
> > Thus I'm wondering whether we shouldn't have a reasonable default
> > for unmarked binaries, presumably based on the system compiler
> > defaults detected at configure time for native builds, and then
> > provide a command allowing the user to override that default?
> 
> Well, that's pretty much what I did for our customer who reported the
> equivalent problem with PowerPC -msoft-float; except instead of
> detecting it at configure time I added a manual configure option
> (since this was for a cross-debugger).
> 
> But it doesn't really scale... I'm open to better ideas...
> 

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Ulrich Weigand]

Luis Machado wrote:

> Isn't GDB currently able to detect the type length in runtime in order
> to correctly print those values?

No, it isn't.  How should GDB recognize the difference?

> With this modification i've noticed that GDB cuts the extra precision
> bytes for a binary built with -mlong-double-64, while printing the value
> with the total avaiable precision when it's built with
> -mlong-double-128.

That's interesting.  GDB will always read in 16 bytes after your
modification -- maybe the binary you're building with -mlong-double-64
happens to have zeros after the "long double" variable your're reading?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Daniel Jacobowitz]

On Mon, Apr 30, 2007 at 02:27:43PM +0200, Ulrich Weigand wrote:
> Luis Machado wrote:
> 
> > Isn't GDB currently able to detect the type length in runtime in order
> > to correctly print those values?
> 
> No, it isn't.  How should GDB recognize the difference?
> 
> > With this modification i've noticed that GDB cuts the extra precision
> > bytes for a binary built with -mlong-double-64, while printing the value
> > with the total avaiable precision when it's built with
> > -mlong-double-128.
> 
> That's interesting.  GDB will always read in 16 bytes after your
> modification -- maybe the binary you're building with -mlong-double-64
> happens to have zeros after the "long double" variable your're reading?

GDB will always read 16 bytes when it uses its built in notion of
"long double".  But if it gets the type from DWARF info, then it will
be an eight byte floating point type, and I bet GDB is automatically
handling it as a double.

That means that the patch is still incorrect, but the consequences of
getting this wrong are not the immediately obvious ones.  I don't know
if saying (long double) in the command line is going to use the type
from debug info or from the gdbarch; our handling of base types has
always confused me somewhat.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

> No, it isn't.  How should GDB recognize the difference?

Doesn't DWARF provide information about this on build time?

> That's interesting.  GDB will always read in 16 bytes after your
> modification -- maybe the binary you're building with -mlong-double-64
> happens to have zeros after the "long double" variable your're reading?

Maybe that's the case. Alignment purposes? 

Regards,
Luis

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

> GDB will always read 16 bytes when it uses its built in notion of
> "long double".  But if it gets the type from DWARF info, then it will
> be an eight byte floating point type, and I bet GDB is automatically
> handling it as a double.
> 
> That means that the patch is still incorrect, but the consequences of
> getting this wrong are not the immediately obvious ones.  I don't know
> if saying (long double) in the command line is going to use the type
> from debug info or from the gdbarch; our handling of base types has
> always confused me somewhat.

Isn't the length of the data type supposed to be available from DWARF?
Or this should still be included by the binaries that actually generate
the DWARF info?

Regards,
Luis

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Daniel Jacobowitz]

On Mon, Apr 30, 2007 at 10:08:48AM -0300, Luis Machado wrote:
> Isn't the length of the data type supposed to be available from DWARF?
> Or this should still be included by the binaries that actually generate
> the DWARF info?

This is "the ABI-defined long double type", which GDB distinguishes
from "the debug info describing long double".  I suppose you could
come up with a way to distinguish binaries based on what their debug
info has to say about it, if it mentions long double anywhere.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

> This is "the ABI-defined long double type", which GDB distinguishes
> from "the debug info describing long double".  I suppose you could
> come up with a way to distinguish binaries based on what their debug
> info has to say about it, if it mentions long double anywhere.

The idea could be that in case a different type is defined in the debug
info than it's in the DWARF info, GDB would stick with what the debug
info says instead.

But then we would rely on debugging info for performing type
identification. What about debugging running processes that do not have
explicit debug info?

Regards,
Luis

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

> The idea could be that in case a different type is defined in the debug
> info than it's in the DWARF info, GDB would stick with what the debug
> info says instead.

Typo here, where it reads DWARF, it's supposed to be ABI.

Regards,
Luis

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Daniel Jacobowitz]

On Mon, Apr 30, 2007 at 10:44:20AM -0300, Luis Machado wrote:
> > This is "the ABI-defined long double type", which GDB distinguishes
> > from "the debug info describing long double".  I suppose you could
> > come up with a way to distinguish binaries based on what their debug
> > info has to say about it, if it mentions long double anywhere.
> 
> The idea could be that in case a different type is defined in the debug
> info than it's in the DWARF info, GDB would stick with what the debug
> info says instead.
> 
> But then we would rely on debugging info for performing type
> identification. What about debugging running processes that do not have
> explicit debug info?

That's exactly the problem.  For the future, I'll try to solve this
using binary tagging.  But for now, I think a user-settable option may
be the best we can do.  Does anyone see a better way?

It may be OK to default to 128-bit long double, since 64-bit long
double "more or less" works anyway.

BTW, the easiest way to see that GDB sometimes uses its builtin types
is to start GDB without any executable, and:

(gdb) p sizeof(1.)
$1 = 8
(gdb) p sizeof(1.f)
$2 = 4
(gdb) p sizeof(1.L)
$3 = 12


-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

Doing a test run with patched version of GDB, i tried "sizeof"-ing the
long double variable on both binaries (one built with -mlong-double-128
and the other with -mlong-double-64).

GDB treats them differently, showing an 8-bytes length for the 64-bit
long double binary and 16-bytes for the 128-bit long double binary.

* 64-bit long doubles

Breakpoint 1, main () at long_double.c:39
39        long_pld(i, ld2, vp1);  /* break here, print ld2, then
continue */
(gdb) p sizeof(ld2)
$1 = 8

* 128-bit long doubles

Breakpoint 1, main () at long_double.c:39
39        long_pld(i, ld2, vp1);  /* break here, print ld2, then
continue */
(gdb) p sizeof(ld2)
$1 = 16

Somehow GDB seems to handle them in different ways.

Regards,
Luis

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Mon, Apr 30, 2007 at 10:44:20AM -0300, Luis Machado wrote:
> > > This is "the ABI-defined long double type", which GDB distinguishes
> > > from "the debug info describing long double".  I suppose you could
> > > come up with a way to distinguish binaries based on what their debug
> > > info has to say about it, if it mentions long double anywhere.

I wasn't aware of that.  I now see that DWARF-2 does provide information
about all "fundamental data types" used by the program; this makes things
a lot easier ...

> > The idea could be that in case a different type is defined in the debug
> > info than it's in the DWARF info, GDB would stick with what the debug
> > info says instead.
> > 
> > But then we would rely on debugging info for performing type
> > identification. What about debugging running processes that do not have
> > explicit debug info?
> 
> That's exactly the problem.  For the future, I'll try to solve this
> using binary tagging.  But for now, I think a user-settable option may
> be the best we can do.  Does anyone see a better way?

Why do we care about the case of programs without debug info?  If we
don't know of any entity of type "long double" because we don't have
debug info, we don't care what that type is either ...

I guess the user could do explicit type casts on the GDB command line,
but then they could just as well explicitly use "double" instead of
"long double" -- that's no more effort than employing a user-settable
option ...

> It may be OK to default to 128-bit long double, since 64-bit long
> double "more or less" works anyway.

Under the circumstances, I'd argue we should just change the built-in
type to 128-bit, and make sure that binaries with a DWARF-2 reported
"long double" fundamental type of 64-bit still use the proper floating
point format info for that type.

Anything I'm missing here?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Daniel Jacobowitz]

On Sun, May 06, 2007 at 11:36:00PM +0200, Ulrich Weigand wrote:
> Under the circumstances, I'd argue we should just change the built-in
> type to 128-bit, and make sure that binaries with a DWARF-2 reported
> "long double" fundamental type of 64-bit still use the proper floating
> point format info for that type.
> 
> Anything I'm missing here?

Sounds reasonable to me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Luis Machado]

On Sun, 2007-05-06 at 18:17 -0400, Daniel Jacobowitz wrote:
> On Sun, May 06, 2007 at 11:36:00PM +0200, Ulrich Weigand wrote:
> > Under the circumstances, I'd argue we should just change the built-in
> > type to 128-bit, and make sure that binaries with a DWARF-2 reported
> > "long double" fundamental type of 64-bit still use the proper floating
> > point format info for that type.
> > 
> > Anything I'm missing here?
> 
> Sounds reasonable to me.

Bringing back the topic. The patch is handling those types as 128-bit in
length by default. Depending on the dwarf info, gdb switches to either
64-bit or 128-bit during printing.

Isn't it right? Maybe i'm missing something regarding GDB's built-in
types for long doubles.

Regards,


-- 
Luis Machado
IBM Linux Technology Center
e-mail: luisgpm@linux.vnet.ibm.com

Re: [RFC] Detecting and printing 128-bit long double values for PPC

[Joseph S. Myers]

On Fri, 31 Aug 2007, Luis Machado wrote:

> Bringing back the topic. The patch is handling those types as 128-bit in
> length by default. Depending on the dwarf info, gdb switches to either
> 64-bit or 128-bit during printing.
> 
> Isn't it right? Maybe i'm missing something regarding GDB's built-in
> types for long doubles.

I have an alternative patch to add 128-bit IBM long double support to GDB 
that I'll submit once Daniel's patch to use object attributes to detect 
the soft-float ABI is in.

My patch has nothing in common with the previous patch 
<http://sourceware.org/ml/gdb-patches/2007-04/msg00368.html>; my 
conclusions were:

* GDB handles floating point using the host's floating point types, using 
the widest one available as DOUBLEST.

* It's OK (as you mention) for GDB's built-in "long double" to have the 
128-bit format unconditionally, since the debug info will identify the 
sizes of the types actually used in the program being debugged.

* However, GDB needs to get the host format right or not set 
gdb_host_long_double_format at all, so where that patch hardcodes it for 
powerpc64-*-* is wrong.

* Setting the host format is only an optimization to avoid excess 
conversions where host and target formats are the same.

* That patch will only work for the native case, because it has no code to 
decode IBM long doubles in other cases.

* GDB needs to know the ABIs used for passing IBM long double arguments.


So what I did was added proper IBM long double support to both libiberty 
and GDB, the patch doing the following:

  - Checking long doubles for validity according to 
    gcc/config/rs6000/darwin-ldouble-format.

  - Converting IBM long doubles to host formats by converting each half 
    and then adding.

  - Converting host doubles to IBM long double by putting 0 in the bottom 
    half.

  - Converting host long doubles to IBM long double by converting to 
    double, putting the result in the top half, and then (except for 
    infinities) subtracting the result from the original value, converting 
    the result of the subtraction to double and putting it in the bottom 
    half.

  - Adding code to ppc-sysv-tdep.c to implement the ABIs for IBM long 
    double arguments correctly.


I did not do anything about host format for powerpc64; that needs autoconf 
detection.

-- 
Joseph S. Myers
joseph@codesourcery.com