`long double' support for ix86 targets

[Mark Kettenis <kettenis@wins.uva.nl>]

Hi,

Kevin's changes to findvar.c:extract_floating() and store_floating()
together with some further analysis have convinced me that for all but
one ix86 targets 96-bit long doubles of type &floatformat_i387_ext are
the right thing.  This would give most of the ix86 targets instant
support for long doubles.  It also gives us the opportunity to remove
some ugly bits introduced by people who tried to hack around the
current limitations.

Here are some personal notes I made about this:

   Support for `long double'
   -------------------------

   The majority of i386 targets in GCC have a `long double' that is
   96 bits wide (of which only 80 bits are used, the rest is padding).
   In fact the only exception is OSF/1, where `long double' is equivalent
   to `double' and has only 64 bits.  This length of 96 bits is also
   used in the debugging information generated by the compiler.

   The origional i386 System V ABI specification doesn't say anything about
   `long double', but the new (draft) IA-64 System V ABI specification
   uses a `long double' of 96 bits for things running in 32-bit mode.
   I guess that 32-bit mode is supposed to be provided for compatible
   with IA-32, this implies that 96 bits is supposed to be the standard.

   Therefore, `config/i386/tm-i386.h' should define:

     #define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
     #define TARGET_LONG_DOUBLE_BITS 96

   Targets such as OSF/1 can override this.

   If we do the above, we can make the default "virtual" type of the FPU
   registers `builtin_type_long_double'.  A lot of the Linux cruft for
   dealing with `long double' could be removed.

I intend to check in the following patch in a week or two, but since
this change affects most of the ix86 targets, I'd like to give people
the opportunity to object.

Mark


2000-03-02  Mark Kettenis  <kettenis@gnu.org>

	* config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
	&floatformat_i387_ext.
	(TARGET_LONG_DOUBLE_BITS): Define as 96.
	(REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
	`builtin_type_long_double'.
	(REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
	with zeroes.
	(REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
	(i387_to_double, double_to_i387): Remove prototypes.


Index: config/i386/tm-i386.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-i386.h
--- config/i386/tm-i386.h	2000/02/29 13:28:24	1.2
+++ config/i386/tm-i386.h	2000/03/03 15:00:49
@@ -1,5 +1,5 @@
 /* Macro definitions for GDB on an Intel i[345]86.
-   Copyright (C) 1995, 1996 Free Software Foundation, Inc.
+   Copyright (C) 1995, 1996, 2000 Free Software Foundation, Inc.
 
    This file is part of GDB.
 
@@ -28,6 +28,19 @@ struct type;
 
 #define TARGET_BYTE_ORDER LITTLE_ENDIAN
 
+/* The format used for `long double' on almost all i386 targets is the
+   i387 extended floating-point format.  In fact, of all targets in the
+   GCC 2.95 tree, only OSF/1 does it different, and insists on having
+   a `long double' that's not `long' at all.  */
+
+#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
+
+/* Although the i386 extended floating-point has only 80 significant
+   bits, a `long double' actually takes up 96, probably to enforce
+   alignment.  */
+
+#define TARGET_LONG_DOUBLE_BITS 96
+
 /* Used for example in valprint.c:print_floating() to enable checking
    for NaN's */
 
@@ -229,7 +242,7 @@ extern int i386_register_virtual_size[];
 #define REGISTER_VIRTUAL_TYPE(N)				\
   (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM)	\
    ? lookup_pointer_type (builtin_type_void)			\
-   : IS_FP_REGNUM(N) ? builtin_type_double			\
+   : IS_FP_REGNUM(N) ? builtin_type_long_double			\
    : IS_SSE_REGNUM(N) ? builtin_type_v4sf			\
    : builtin_type_int)
 
@@ -239,25 +252,22 @@ extern int i386_register_virtual_size[];
    that SSE registers need conversion.  Even if we can't find a
    counterexample, this is still sloppy.  */
 #define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n))
-
-/* Convert data from raw format for register REGNUM in buffer FROM
-   to virtual format with type TYPE in buffer TO.  */
-extern void i387_to_double (char *, char *);
 
+/* Convert data from raw format for register REGNUM in buffer FROM to
+   virtual format with type TYPE in buffer TO.  In principle both
+   formats are identical except that the virtual format has two extra
+   bytes appended that aren't used.  We set these to zero.  */
 #define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO)	\
-{								\
-  double val;							\
-  i387_to_double ((FROM), (char *)&val);			\
-  store_floating ((TO), TYPE_LENGTH (TYPE), val);		\
-}
-
-extern void double_to_i387 (char *, char *);
-
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO)		\
-{								\
-  double val = extract_floating ((FROM), TYPE_LENGTH (TYPE));	\
-  double_to_i387((char *)&val, (TO));				\
-}
+  {								\
+    memset ((TO), 0, TYPE_LENGTH (TYPE));			\
+    memcpy ((TO), (FROM), FPU_REG_RAW_SIZE);			\
+  }
+
+/* Convert data from virtual format with type TYPE in buffer FROM to
+   raw format for register REGNUM in buffer TO.  Simply omit the two
+   unused bytes.  */
+#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
+  memcpy ((TO), (FROM), FPU_REG_RAW_SIZE)
 
 /* Print out the i387 floating point state.  */
 #ifdef HAVE_I387_REGS
From fnasser@redhat.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Chris Faylor <cgf@cygnus.com>, gdb-patches@sourceware.cygnus.com, Fernando Nasser <fnasser@cygnus.com>
Subject: Re: Add support for WinCE toolchains
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B4A305.268575@redhat.com>
References: <200002222350.PAA09035@elmo.cygnus.com> <200002230024.TAA11216@envy.delorie.com> <38B32E01.34616D70@apple.com> <88vbe5$4r5$1@cronkite.cygnus.com> <88vrpb$bs1$1@cronkite.cygnus.com> <38B376E2.6ABAE68D@cygnus.com>
X-SW-Source: 2000-q1/msg00349.html
Content-length: 1659

Sorry for the delay -- too many meetings today.

Yes, sure.  The new files in config/arm are fine.

Cheers,
Fernando

Andrew Cagney wrote:
> 
> Chris Faylor wrote:
> >
> > In article < 88vbe5$4r5$1@cronkite.cygnus.com >,
> > Chris Faylor <cgf@cygnus.com> wrote:
> > >One of the things I've done is to regularize the name of files that I
> > >used.  Everything has a "wince" in it now since the WinCE version of PE
> > >is apparently non-standard.  I've also moved WinCE-specific code out of
> > >the generic target files into their own files.
> >
> > Here is an addition/modification to what Nick Clifton had previously
> > proposed.  Most of the files are the same with the exception of
> > configure.tgt and the addition of some new target files in the
> > appropriate directories.  Per Andrew's request, there are no
> > modifications to any other files in config/*.
> >
> > cgf
> >
> > 2000-02-23  Christopher Faylor  <cgf@cygnus.com>
> >
> >         * configure.tgt: Add arm, mips, sh wince targets.
> >         * config/arm/tm-wince.h: New file.
> >         * config/arm/wince.mt New file.
> >         * config/sh/tm-wince.h: New file.
> >         * config/sh/wince.mt New file.
> >         * config/mips/tm-wince.h: New file.
> >         * config/mips/wince.mt New file.
> 
> The configury plus config/sh and config/mips stuff are both ok with me.
> I'm 99% sure that the config/arm stuff would be ok with Fernando.
> 
>         Andrew

-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Subject: Patch to fix thread support for Solaris x86
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002261228.NAA32377@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00370.html
Content-length: 811

This patch fixes thread support for Solaris x86 platforms.

The patch gets rid of the following testsuite fail and causes no regressions:
FAIL: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2

2000-02-26  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>

	* config/i386/tm-i386sol2.h (MERGEPID):  Define.

*** ./config/i386/tm-i386sol2.h.orig	Tue Jan 11 04:07:28 2000
--- ./config/i386/tm-i386sol2.h	Sat Feb 26 11:32:13 2000
***************
*** 45,49 ****
--- 51,56 ----
  /* Macros to extract process id and thread id from a composite pid/tid */
  #define PIDGET(pid) ((pid) & 0xffff)
  #define TIDGET(pid) (((pid) >> 16) & 0xffff)
+ #define MERGEPID(pid, tid) (((tid) << 16) | (pid))
  
  #endif /* ifndef TM_I386SOL2_H */

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>, jsm@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Remove gdb.base/annota2.exp
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14450.18810.565455.834962@kwikemart.cygnus.com>
References: <200001020540.AAA31521@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00005.html
Content-length: 882

Jim Kingdon writes:
 > Some time ago, gdb.base/annota2.exp got copied to gdb.c++/annota2.exp.
 > However (due to oversight?), gdb.base/annota2.exp didn't get deleted
 > and in the meantime various bugfixes have been applied to
 > gdb.c++/annota2.exp and not gdb.base/annota2.exp.  Here's a suggested
 > ChangeLog entry for doing it now (I'm not submitting a diff, as there
 > are no changes other than deleting the file).
 > 
 > Perhaps this is an artifact of the way that GDB is moved over to
 > cvs.sourceware.com?  If so, the fix might be different...
 > 
 > 2000-01-01  Jim Kingdon  < http://developer.redhat.com/ >
 > 
 > 	* gdb.base/annota2.exp: Removed; gdb.c++/annota2.exp has all
 > 	the good bits from gdb.base/annota2.exp.

It seems that the file was correctly removed from the cvs repository
some time ago. I suspect something went wrong on sourceware.
Jason?

Elena