public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* [Fwd: FLOAT INFO QUESTION]
@ 2000-06-23  6:57 Andrew Cagney
  2000-06-23  7:21 ` Fernando Nasser
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Cagney @ 2000-06-23  6:57 UTC (permalink / raw)
  To: GDB Discussion

 


To : ac131313 at cygnus dot com
Subject : FLOAT INFO QUESTION
From : Takis Psarogiannakopoulos <takis at XFree86 dot Org>
Date : Thu, 22 Jun 2000 07:07:21 -0700 (PDT)


Can you please forward this to the gdb list ?
It keeps sending it back. XFREE86 is a junk mail
server? 

Thanks very much,
Takis
PS: Remove the above comment ...

---------- Forwarded message ----------
Date: Thu, 22 Jun 2000 06:47:32 -0700 (PDT)
From: takis@xfree86.org
To: gdb@sourceware.cygnus.com
Subject: FLOAT INFO QUESTION


Hello,
I had a look in the new float info routines
of gdb 5.0 and I am a little confused. If you look
in <linux/processor.h> you will find that the 387 
structure is like 
        cwd (fctrl)
        swd (fstat)
        twd (ftag)
        fip
        fcs
        foo
        80 bytes = 8*10  
        status

Now in the operating system that I run (aka DG/UX unix)
and want to do a port of 5.0, I find the structure:

struct fpregset {
           
             union{

                    struct fpchip_state fpchip_state;
                    emulation struct
                    int f_fpreg[62];
                  }

                  long f_wregs[33]; /* weitek */
                 }

Where: struct fpchip_state {
                  int state[27];
                  int status;
                 }

So the first member reserves 108 bytes = 7 4 bytes fpregs + 8 *10.
Tah agrees with the linux idea.

Now in GDB-5.0 we find in tm-i386.h a new layout as

   fctrl, fstat, ftag, fiseg, fioff, foseg, fooff, fop

Which is clearly different from the struct of linux. Basically          
if I want to unpack fpchip_state above to floating regs I dont know
if the order is fctrl, fstat, ftag , fiseg(=fcs), fioff(=?) , ????
or (what I always thought is)

  fctrl,fstat,ftag,fip,fcs,fopoff,fopsel,status

And in this new layout in tm-i386.h which one is the status? I
clearly have 108 bytes so how I would obtain the fop 
mentioned in tm-i386.h?

Regards, 
T.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Fwd: FLOAT INFO QUESTION]
  2000-06-23  6:57 [Fwd: FLOAT INFO QUESTION] Andrew Cagney
@ 2000-06-23  7:21 ` Fernando Nasser
  2000-06-23 15:38   ` SourceNavigator? I don't know this muller
  0 siblings, 1 reply; 3+ messages in thread
From: Fernando Nasser @ 2000-06-23  7:21 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: GDB Discussion

The layout in tm-i386.h is how gdb wants to see things.
Each target, either native or remote, has to read the registers
and store them in that exact order/layout in the register file.

So you use your OS syscall to read the registers and copy them
to the register file placing them in the right places.

Look what i386-linux-tdep.c does.

Fernando

P.S.: I would suggest that anyone trying to understand how some
code works downloads and starts using SourceNavigator.  Your lives
will become considerable less complicated (at least in the hacking
front ;-).


> Date: Thu, 22 Jun 2000 06:47:32 -0700 (PDT)
> From: takis@xfree86.org
> To: gdb@sourceware.cygnus.com
> Subject: FLOAT INFO QUESTION
> 
> Hello,
> I had a look in the new float info routines
> of gdb 5.0 and I am a little confused. If you look
> in <linux/processor.h> you will find that the 387
> structure is like
>         cwd (fctrl)
>         swd (fstat)
>         twd (ftag)
>         fip
>         fcs
>         foo
>         80 bytes = 8*10
>         status
> 
> Now in the operating system that I run (aka DG/UX unix)
> and want to do a port of 5.0, I find the structure:
> 
> struct fpregset {
> 
>              union{
> 
>                     struct fpchip_state fpchip_state;
>                     emulation struct
>                     int f_fpreg[62];
>                   }
> 
>                   long f_wregs[33]; /* weitek */
>                  }
> 
> Where: struct fpchip_state {
>                   int state[27];
>                   int status;
>                  }
> 
> So the first member reserves 108 bytes = 7 4 bytes fpregs + 8 *10.
> Tah agrees with the linux idea.
> 
> Now in GDB-5.0 we find in tm-i386.h a new layout as
> 
>    fctrl, fstat, ftag, fiseg, fioff, foseg, fooff, fop
> 
> Which is clearly different from the struct of linux. Basically
> if I want to unpack fpchip_state above to floating regs I dont know
> if the order is fctrl, fstat, ftag , fiseg(=fcs), fioff(=?) , ????
> or (what I always thought is)
> 
>   fctrl,fstat,ftag,fip,fcs,fopoff,fopsel,status
> 
> And in this new layout in tm-i386.h which one is the status? I
> clearly have 108 bytes so how I would obtain the fop
> mentioned in tm-i386.h?
> 
> Regards,
> T.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* SourceNavigator? I don't know this.
  2000-06-23  7:21 ` Fernando Nasser
@ 2000-06-23 15:38   ` muller
  0 siblings, 0 replies; 3+ messages in thread
From: muller @ 2000-06-23 15:38 UTC (permalink / raw)
  To: Fernando Nasser; +Cc: GDB Discussion

>P.S.: I would suggest that anyone trying to understand how some
>code works downloads and starts using SourceNavigator.  Your lives
>will become considerable less complicated (at least in the hacking
>front ;-).

  What is this program, is it free,
do you have an URL?

  If you recommend it, I am willing to try it!

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-06-23 15:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-23  6:57 [Fwd: FLOAT INFO QUESTION] Andrew Cagney
2000-06-23  7:21 ` Fernando Nasser
2000-06-23 15:38   ` SourceNavigator? I don't know this muller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).