From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: `long double' support for ix86 targets Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003031531.e23FV8T00285@delius.kettenis.local> X-SW-Source: 2000-q1/msg00473.html 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 * 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 To: Andrew Cagney Cc: Chris Faylor , gdb-patches@sourceware.cygnus.com, Fernando Nasser 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 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 > > > > * 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" 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 * 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 To: Jim Kingdon , 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