From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: hjl@lucon.org (H.J. Lu) Cc: kettenis@wins.uva.nl (Mark Kettenis), gdb@sourceware.cygnus.com, jtc@redback.com, jimb@cygnus.com Subject: Re: x86 FPU support: "info float" and `long double' Date: Thu, 21 Oct 1999 10:41:00 -0000 Message-id: <199910211740.NAA00651@mescaline.gnu.org> References: <19991021171307.87FEC1B493@ocean.lucon.org> X-SW-Source: 1999-q4/msg00099.html > 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 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 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