From mboxrd@z Thu Jan 1 00:00:00 1970 From: hjl@lucon.org (H.J. Lu) To: eliz@gnu.org (Eli Zaretskii) Cc: hjl@lucon.org (H.J. Lu), 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:49:00 -0000 Message-id: <19991021174922.E4F5A1B493@ocean.lucon.org> References: <199910211740.NAA00651@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00101.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. > That is a good point. I am used to check fstat: 0x0000 flags 0000; top 0; for where the real st0 is. -- H.J. Lu (hjl@gnu.org) >From kevinb@cygnus.com Thu Oct 21 11:19:00 1999 From: Kevin Buettner To: Stan Shebs , 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 11:19:00 -0000 Message-id: <991021181855.ZM3563@ocotillo.lan> References: <199910211743.KAA08509@andros.cygnus.com> X-SW-Source: 1999-q4/msg00102.html Content-length: 2848 On Oct 21, 10:43am, Stan Shebs wrote: > 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? I got my patches working with the head of the development tree several weeks ago. (Actually, Gary Thomas deserves a lot of the credit.) However there are a great many similarities between rs6000-tdep.c and the ppclinux-tdep.c. I would really like to make the common parts truly common as well as revamp it so that it uses the gdbarch machinery, but this'll take more time than I have at the moment. So it might be better for me to commit what I have so that linux/ppc is supported in the Cygnus tree. Also, the longer I let my stuff sit, the more likely it is that certain global changes will break what I have working already. (Because these global changes won't have happened to the linux/ppc stuff.) > 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). I'll take this opportunity to agree with Kevin Hendricks regarding HJ's Linux tools. Even on Linux/x86 where there was some existing gdb support in the FSF tree, HJ's splinter version of gdb made it possible to debug multi-threaded programs on Linux. When I was developing Linux applications at Metrowerks, we appreciated this greatly and would probably not have been able to complete our product in a timely fashion without his splinter version. Kevin >From khendricks@admin.ivey.uwo.ca Thu Oct 21 11:21:00 1999 From: Kevin_Hendricks To: khendricks@admin.ivey.uwo.ca, shebs@cygnus.com Cc: hjl@lucon.org, jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: x86 fpu Date: Thu, 21 Oct 1999 11:21:00 -0000 Message-id: <11999.940530080.0@NO-ID-FOUND.mhonarc.org> X-SW-Source: 1999-q4/msg00103.html Content-length: 1177 Hi, >It's never going to be possible for FSF GDB to have the latest version >of every code bit that is under development. It is just that your "code bit" is our complete world. Gdb is the *only* debugger that exists for Linux PPC. We have nothing else to fall back on. >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) Yes, that is very true. I could not understand why it took so much just to get ppc support in (I didn't know RMS and MW president had to get involved.) >However, we should always be trying to >stay as current as possible. Sounds good to me. After how quickly Kevin Buettner got JDK 1.1.X working under Linux PPC (when only working part time on the porting team), I am sure he will have us (LinuxPPC) in good shape with gdb in no time at all! Thanks, Kevin -- Kevin B. Hendricks Associate Professor of Operations and Information Technology Richard Ivey School of Business, University of Western Ontario London, Ontario N6A-3K7 CANADA khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959