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

[hjl@lucon.org (H.J. Lu)]

> 
> > 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 <kevinb@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>, 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> <shebs@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 <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?

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 <khendricks@admin.ivey.uwo.ca>
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