Re: Regressions problem (200 failures)

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> writes:

    Peter> with GCC or GDB), a breakpoint on the opening brace is not
    Peter> what I want, as I will almost always have to step over it.
    Peter> I'd expect a breakpoint on the first local variable that
    Peter> needs initalization, or the first statement.

Yes, I think we're all agreed.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From mark@codesourcery.com Thu Mar 02 08:59:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: kettenis@wins.uva.nl
Cc: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Thu, 02 Mar 2000 08:59:00 -0000
Message-id: <20000302090701N.mitchell@codesourcery.com>
References: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> <20000302023420H.mitchell@codesourcery.com> <200003021246.e22CkWL00549@delius.kettenis.local>
X-SW-Source: 2000-03/msg00047.html
Content-length: 937

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

    Mark> some bit rot since then.  Are the prologue's generated by
    Mark> GCC any different from those generated back in 1994?

I dunno, but my guess is that's not the bug.

Right now, the problem is:

  o We put line notes in the prologue

  o We weren't putting line notes before the first real code, so
    GCC was skipping over that too.

  o I promoted the last line note in the prologue to appear before
    the first real code, bringing GCC back to seme-sensible behavior.

We could try to:

  o Not emit line notes in the prologue that correspond to the '{'
    line.
 
  o Try to find the first line note in the real code, instead of
    the last line note in the prologue.

The latter is probably easiest, but is still harder that what I did.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From gzp@gzp.org.hu Thu Mar 02 11:48:00 2000
From: "Gabor Z. Papp" <gzp@gzp.org.hu>
To: gdb@sourceware.cygnus.com
Subject: gdb cvs
Date: Thu, 02 Mar 2000 11:48:00 -0000
Message-id: <20000302204824.B18856@gzp.org.hu>
References: <200003021924.e22JO4U19747@mail.gzp.org.hu>
X-SW-Source: 2000-03/msg00048.html
Content-length: 5091

| cvs server: Updating gdb
| U gdb/CONTRIBUTE

[...]

| U gdb/vx-share/xdr_rdb.h
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/texinfo
| cvs server: ignoring module src/texinfo
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/bfd
| cvs server: ignoring module src/bfd
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/opcodes
| cvs server: ignoring module src/opcodes
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/readline
| cvs server: ignoring module src/readline
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/libiberty
| cvs server: ignoring module src/libiberty
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/mmalloc
| cvs server: ignoring module src/mmalloc
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/include
| cvs server: ignoring module src/include
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/sim
| cvs server: ignoring module src/sim
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/utils
| cvs server: ignoring module src/utils
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/.cvsignore
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/COPYING
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/COPYING.LIB
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ChangeLog
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/Makefile.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/README
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/config
| cvs server: ignoring module src/config
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config-ml.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.guess
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.if
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.sub
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/configure
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/configure.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/etc
| cvs server: ignoring module src/etc
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/install-sh
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ltconfig
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ltmain.sh
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/makefile.vms
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/missing
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mkdep
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mkinstalldirs
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/move-if-change
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-README
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-build.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-config.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-configure
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-install
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/setup.com
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/symlink-tree
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ylwrap
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/intl
| cvs server: ignoring module src/intl

Is this correct?
From ac131313@cygnus.com Thu Mar 02 16:22:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Gabor Z. Papp" <gzp@gzp.org.hu>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb cvs
Date: Thu, 02 Mar 2000 16:22:00 -0000
Message-id: <38BF0551.9B4FE1E@cygnus.com>
References: <200003021924.e22JO4U19747@mail.gzp.org.hu> <20000302204824.B18856@gzp.org.hu>
X-SW-Source: 2000-03/msg00049.html
Content-length: 299

"Gabor Z. Papp" wrote:
> 
> | cvs server: Updating gdb
> | U gdb/CONTRIBUTE
> 
> [...]
> 

> 
> Is this correct?

Were you doing a: ``co gdb'' over the top of an existing tree?  I've
encountered that message then.
I suspect it isn't correct but, from what I saw it still did what I
wanted.

	Andrew
From muller@cerbere.u-strasbg.fr Fri Mar 03 00:28:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 00:28:00 -0000
Message-id: <200003030843.JAA12246@cerbere.u-strasbg.fr>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00050.html
Content-length: 1161

I inserted this in a reply about pascal extension, but as I got no answer,
I thought
I will send it as a separate message.

I have written for DJGPP target a relatively small patch.
It allows to read memory from another selector
this was very useful for me when I tried to debug the debugger itself and 
when I added exception support fro GDB on DJGPP !

This patch consists of the addition of one command that I called "xx"
which is a simple clone of the "x" command but can take a selector 
as for intance 
   "xx $fs:0x400"
then the next "xx 0x800" keeps using the last selector value.
I do not know if this could be interesting for other i386 targets
(maybe for win32 to be able to see the content of the $fs selector
that contains the exception chain, but I am not sure how if its
readable inside a win32 API program).

  Is such kind of patch too specific to have any chance to get accepted ?
I don't know if it could be of any use for other processors or operating
system !!




Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From ac131313@cygnus.com Fri Mar 03 00:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: tromey@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Fri, 03 Mar 2000 00:56:00 -0000
Message-id: <38BF7E1D.4E0A904D@cygnus.com>
References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com>
X-SW-Source: 2000-03/msg00051.html
Content-length: 354

Tom Tromey wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> Andrew> GNU/Linux/i386:
> 
> Without my patch, gdb doesn't work at all when run on x86 Linux boxes
> with older kernels (I still run 2.0.34).

Tom,

I belive JimB's bubbled this up to the top of his queue and made it one
of the things try to get into 5.0

	Andrew
From ac131313@cygnus.com Fri Mar 03 01:16:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: 5.0 known issues 2000-02-16
Date: Fri, 03 Mar 2000 01:16:00 -0000
Message-id: <38BF81BD.C7C35B59@cygnus.com>
References: <Pine.LNX.4.10.10002161044530.25408-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00052.html
Content-length: 699

Jimmy Guo wrote:
> 
> >HP/UX: Unfortunately this was knocked about pretty badly by the move to
> >an external repository (sorry). Jimmy's looking at it along with Jason
> >and (possibly) Jeff (shared lib problem).  I'm also going to try get
> >access to a HPUX box and give it a whirl.
> 
> Provided that Jeff has applied the changes (include/hp-symtab.h) into
> the public repository, GDB should build for HP targets.
> 
> Currently we're still relying on weekly snapshots to pick up updates.  I
> know this would have to change for us to access CVS directly ... once
> there's a snapshot I will see if it is fixed ...

Just FYI, Hopefully the weekly snapshots are starting to flow again.

	Andrew
From insulaner_andi@yahoo.com Fri Mar 03 02:18:00 2000
From: Andreas Kuepper <insulaner_andi@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: running GDB on Cygwin
Date: Fri, 03 Mar 2000 02:18:00 -0000
Message-id: <20000303101528.22003.qmail@web3402.mail.yahoo.com>
X-SW-Source: 2000-03/msg00053.html
Content-length: 364

Is there anybody who ever tried to run GDB on Cygwin?

I want to do remote debugging and when I run
"configure" it fails with the message :

configure: error: could not find term library

Thanks for your help!

Andreas Kuepper
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From kettenis@wins.uva.nl Fri Mar 03 04:40:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: muller@cerbere.u-strasbg.fr
Cc: gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 04:40:00 -0000
Message-id: <200003031240.e23CeRn00162@delius.kettenis.local>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00054.html
Content-length: 1571

   Date: Fri, 03 Mar 2000 09:27:14 +0100
   From: Pierre Muller <muller@cerbere.u-strasbg.fr>

   I inserted this in a reply about pascal extension, but as I got no answer,
   I thought
   I will send it as a separate message.

Sorry about that.

   I have written for DJGPP target a relatively small patch.
   It allows to read memory from another selector
   this was very useful for me when I tried to debug the debugger itself and 
   when I added exception support fro GDB on DJGPP !

   This patch consists of the addition of one command that I called "xx"
   which is a simple clone of the "x" command but can take a selector 
   as for intance 
      "xx $fs:0x400"
   then the next "xx 0x800" keeps using the last selector value.
   I do not know if this could be interesting for other i386 targets
   (maybe for win32 to be able to see the content of the $fs selector
   that contains the exception chain, but I am not sure how if its
   readable inside a win32 API program).

     Is such kind of patch too specific to have any chance to get accepted ?
   I don't know if it could be of any use for other processors or operating
   system !!

This may be impossible to implement on most i386 targets (with the
possible exception of Solaris and Mach-based targets), but nevrtheless
it could be useful to have for things that are a bit more low-level
(like debugging a threads library that uses segmentation to store
per-thread data and such).  The suggested syntax could probably be
improved, since "xx" isn't very descriptive.  People with bright ideas?

Mark
From ac131313@cygnus.com Fri Mar 03 04:52:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Fri, 03 Mar 2000 04:52:00 -0000
Message-id: <38BFB50A.606036CF@cygnus.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00055.html
Content-length: 1420

Pierre Muller wrote:
> 
> I inserted this in a reply about pascal extension, but as I got no answer,
> I thought
> I will send it as a separate message.
> 
> I have written for DJGPP target a relatively small patch.
> It allows to read memory from another selector
> this was very useful for me when I tried to debug the debugger itself and
> when I added exception support fro GDB on DJGPP !
> 
> This patch consists of the addition of one command that I called "xx"
> which is a simple clone of the "x" command but can take a selector
> as for intance
>    "xx $fs:0x400"
> then the next "xx 0x800" keeps using the last selector value.
> I do not know if this could be interesting for other i386 targets
> (maybe for win32 to be able to see the content of the $fs selector
> that contains the exception chain, but I am not sure how if its
> readable inside a win32 API program).
> 
>   Is such kind of patch too specific to have any chance to get accepted ?
> I don't know if it could be of any use for other processors or operating
> system !!

I'm not sure what the x86 people will do.

However the generic problem of getting GDB to understand segments is one
of those things that has long sat on peoples wishlists.

The theory is that if ``CORE_ADDR'' is made in to a pretend object
(ISO-C remember :-) and then the rest falls out....  As they say, the
proof is left as an exercise to the reader.

	enjoy,
		Andrew
From muller@cerbere.u-strasbg.fr Fri Mar 03 06:47:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb@sourceware.cygnus.com
Subject: 2 pascal language patches inserted in database
Date: Fri, 03 Mar 2000 06:47:00 -0000
Message-id: <200003031500.QAA18276@cerbere.u-strasbg.fr>
References: <200003021452.PAA02334@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-03/msg00056.html
Content-length: 423

  I submitted two patches for pascal extension in the database!

  I am subscribed to gdb-patches and I think that this should be enough to
gt also 
all mails generated by the gdb patch database, but I saw a
subcribe link! Why is this distinct ?


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From hjl@lucon.org Fri Mar 03 07:17:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: tromey@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Fri, 03 Mar 2000 07:17:00 -0000
Message-id: <20000303071729.B31569@lucon.org>
References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com> <38BF7E1D.4E0A904D@cygnus.com>
X-SW-Source: 2000-03/msg00057.html
Content-length: 705

On Fri, Mar 03, 2000 at 07:55:57PM +1100, Andrew Cagney wrote:
> Tom Tromey wrote:
> > 
> > >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> > 
> > Andrew> GNU/Linux/i386:
> > 
> > Without my patch, gdb doesn't work at all when run on x86 Linux boxes
> > with older kernels (I still run 2.0.34).
> 
> Tom,
> 
> I belive JimB's bubbled this up to the top of his queue and made it one
> of the things try to get into 5.0

FWIW, the static gdb binary of gdb 4.17.0.1x compiled with glibc 2.1
and kernel 2.2 works on kernel >= 2.0, libc 5, glibc 2.0 and glibc
2.1. It should also work on glibc 2.2. Kernel and libc are detected at
the runtime. It will be nice that 5.0 can do the same.



H.J.
From kettenis@wins.uva.nl Fri Mar 03 07:31:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: `long double' support for ix86 targets
Date: Fri, 03 Mar 2000 07:31:00 -0000
Message-id: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-03/msg00058.html
Content-length: 5450

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 ezannoni@cygnus.com Fri Mar 03 07:52:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: PATCH: Eliminate some uses of PTR.
Date: Fri, 03 Mar 2000 07:52:00 -0000
Message-id: <14527.57252.598442.150750@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00059.html
Content-length: 4376

This eliminates uses of PTR from event-loop.h, event-top.c.

I've checked this in.

Elena

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.96
diff -c -r1.96 ChangeLog
*** ChangeLog	2000/03/03 02:18:26	1.96
--- ChangeLog	2000/03/03 15:26:44
***************
*** 1,3 ****
--- 1,12 ----
+ 2000-03-03  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
+ 
+ 	* defs.h (struct continuation_arg): Change type of field 'data'
+  	from PTR to void *.
+ 
+ 	* event-loop.h: Eliminate uses of PTR, use 'void *' instead.
+ 
+ 	* event-top.c: Ditto.
+ 
  2000-03-02  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
  
  	* config/alpha/alpha-linux.mh: Remove core-regset.o fron the
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.4
diff -c -r1.4 defs.h
*** defs.h	2000/02/24 00:04:03	1.4
--- defs.h	2000/03/03 15:26:44
***************
*** 613,619 ****
  struct continuation_arg
    {
      struct continuation_arg *next;
!     PTR data;
    };
  
  struct continuation
--- 613,619 ----
  struct continuation_arg
    {
      struct continuation_arg *next;
!     void *data;
    };
  
  struct continuation
Index: event-loop.h
===================================================================
RCS file: /cvs/src/src/gdb/event-loop.h,v
retrieving revision 1.1.1.15
diff -c -r1.1.1.15 event-loop.h
*** event-loop.h	1999/10/05 23:08:11	1.1.1.15
--- event-loop.h	2000/03/03 15:26:44
***************
*** 57,63 ****
  
     Corollary tasks are the creation and deletion of event sources. */
  
! typedef PTR gdb_client_data;
  struct async_signal_handler;
  typedef void (handler_func) (int, gdb_client_data);
  typedef void (sig_handler_func) (gdb_client_data);
--- 57,63 ----
  
     Corollary tasks are the creation and deletion of event sources. */
  
! typedef void * gdb_client_data;
  struct async_signal_handler;
  typedef void (handler_func) (int, gdb_client_data);
  typedef void (sig_handler_func) (gdb_client_data);
Index: event-top.c
===================================================================
RCS file: /cvs/src/src/gdb/event-top.c,v
retrieving revision 1.2
diff -c -r1.2 event-top.c
*** event-top.c	2000/02/23 00:25:42	1.2
--- event-top.c	2000/03/03 15:26:44
***************
*** 129,145 ****
     handlers mark these functions as ready to be executed and the event
     loop, in a later iteration, calls them. See the function
     invoke_async_signal_handler. */
! PTR sigint_token;
  #ifdef SIGHUP
! PTR sighup_token;
  #endif
! PTR sigquit_token;
! PTR sigfpe_token;
  #if defined(SIGWINCH) && defined(SIGWINCH_HANDLER)
! PTR sigwinch_token;
  #endif
  #ifdef STOP_SIGNAL
! PTR sigtstp_token;
  #endif
  
  /* Structure to save a partially entered command.  This is used when
--- 129,145 ----
     handlers mark these functions as ready to be executed and the event
     loop, in a later iteration, calls them. See the function
     invoke_async_signal_handler. */
! void *sigint_token;
  #ifdef SIGHUP
! void *sighup_token;
  #endif
! void *sigquit_token;
! void *sigfpe_token;
  #if defined(SIGWINCH) && defined(SIGWINCH_HANDLER)
! void *sigwinch_token;
  #endif
  #ifdef STOP_SIGNAL
! void *sigtstp_token;
  #endif
  
  /* Structure to save a partially entered command.  This is used when
***************
*** 525,532 ****
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
        arg1->next = arg2;
        arg2->next = NULL;
!       arg1->data = (PTR) time_at_cmd_start;
!       arg2->data = (PTR) space_at_cmd_start;
        add_continuation (command_line_handler_continuation, arg1);
      }
  
--- 525,532 ----
  	(struct continuation_arg *) xmalloc (sizeof (struct continuation_arg));
        arg1->next = arg2;
        arg2->next = NULL;
!       arg1->data = (void *) time_at_cmd_start;
!       arg2->data = (void *) space_at_cmd_start;
        add_continuation (command_line_handler_continuation, arg1);
      }
  
***************
*** 957,963 ****
  }
  
  void
! mark_async_signal_handler_wrapper (PTR token)
  {
    mark_async_signal_handler ((struct async_signal_handler *) token);
  }
--- 957,963 ----
  }
  
  void
! mark_async_signal_handler_wrapper (void *token)
  {
    mark_async_signal_handler ((struct async_signal_handler *) token);
  }
From kettenis@wins.uva.nl Fri Mar 03 08:36:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: msnyder@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: lin-thread cannot handle thread exit
Date: Fri, 03 Mar 2000 08:36:00 -0000
Message-id: <200003031635.e23GZwi00372@delius.kettenis.local>
X-SW-Source: 2000-03/msg00060.html
Content-length: 1394

Hi Michael,

The thread_db assisted debugging code doesn't handle exiting threads
properly, at least in combination with glibc 2.1.3.  There are at
least two problems that prevent this from working:

1. In lin-thread.c:enable_thread_event_reporting(), GDB requests
   TD_DEATH events to be reported, and sets a breakpoint at the
   appropriate location.  The problem is that the LinuxThreads
   implementation included with glibc 2.1.3 triggers that breakpoint
   after it has flagged the thread as terminated.  As a conseuqence
   when GDB tries to fetch the registers for that thread it doesn't
   succeed, and GDB complains about a breakpoint at location 0x0 that
   it doesn't know of.

2. If I disable the reporting of TD_DEATH events, things still don't
   work.  The problem is that when the thread really exits, a
   TARGET_WAITKIND_EXITED event is reported to GDB in.  So the answer to
   the question ``Can I get this event mistakenly from a thread?'' in
   lin-thread.c:thread_db_wait() is ``Yes''.  Since the
   TARGET_WAITKIND_EXITED event is passed on to other code in GDB, GDB
   thinks that the entire process has died.

Ignoring those "spurious" TARGET_WAITKIND_EXITED events doesn't help
since some parts of GDB still think that the thread is still alive
then.

Looking through the code, it seems that there quite a few "loose
ends".  Is this still "work in progress"?

Mark