Re: x86 FPU support: "info float" and `long double'

[Eli Zaretskii <eliz@gnu.org>]

> My current gdb has
> 
> (gdb) info float
>      st0: 0x3ffed6d6d6d6d6d6d800  Empty Normal 0.8392156862745098200307
>      st1: 0x00000000000000000000  Empty Zero   0

"st0", "st1" etc. implies stack-relative order of the registers.
IMHO, this is wrong: it doesn't present the registers as a stack, and
with each push/pop operation, the entire picture moves up/down, which
is very confusing.  If this format is adopted (I hope not), it won't
make sense to print the TOS pointer (that arrow => shown by Mark in
his example), since the TOS is always st0.

In the physical order, like what go32-nat.c does, the registers cannot
be designated st0, st1, etc., because that's not true.  If 0, 1,
etc. is somehow not good enough, we should use R0, R1, etc., like
Intel does.
From shebs@cygnus.com Thu Oct 21 10:43:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: khendricks@admin.ivey.uwo.ca
Cc: hjl@lucon.org, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 10:43:00 -0000
Message-id: <199910211743.KAA08509@andros.cygnus.com>
References: <199910211413.HAA06667@cygnus.com>
X-SW-Source: 1999-q4/msg00100.html
Content-length: 1974

   Date: Thu, 21 Oct 1999 10:11:22 -0400 (EDT)
   From: Kevin_Hendricks <khendricks@admin.ivey.uwo.ca>

   For example, before Kevin Buettner officially joined gdb, the powerpc camp was 
   out on its own. Many months ago (a year?) we tried to get gdb to support PPC in 
   gdb 4.17 by contributing a patch which was rejected since its author (Kevin 
   Buettner) had not recently signed a copyright assignment (although he had in the 
   past).  We requested the proper forms but nothing ever came from it.

Actually, all that did happen a while back - it ended up requiring
some negotiation between Metrowerks' president and RMS (amusing to
think about), since Kevin B was working for MW at the time.  I think
we're all glad that MW, which might someday come to regard GDB as a
competitor on LinuxPPC, does not have a legal way to interfere with
its development...

I must confess I'm not up on the technical state of LinuxPPC patches
however; I remember Kevin B wanting to make some further changes
before incorporating.  Kevin?

   Meanwhile H.J. Lu's gdb included ppc support and even includes linuxthreads 
   support (which finally made it possible for me to debug native_threads JDK's as 
   part of the Blackdown effort). If I had waited for "official" support, all 
   development would have ground to a halt long ago.

   Basically, H.J. Lu's tools have simply been a big help.   
   His tools have filled a need that the GDB effort should have been filling.  If 
   they had, there would have been no need for a splinter in the first place (as I 
   think Stan pointed out).

It's never going to be possible for FSF GDB to have the latest version
of every code bit that is under development.  If nothing else, most of
the Linux folks take a rather cavalier attitude towards copyright
ownership, and FSF policy does not allow us to do that for GDB.
(complaints to rms@gnu.org)  However, we should always be trying to
stay as current as possible.


								Stan