This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: i386: Are we settled?


   Date: Mon, 8 Nov 1999 19:18:11 -0500 (EST)
   From: Jim Blandy <jimb@cygnus.com>

   Are we settled on the essential contents of tm-i386.h?  Can we start
   removing the little [regs] and [fpregs] boxes from
   http://sourceware.cygnus.com/gdb/papers/linux/i386-includes.png?

Maybe it would be a good idea to change the #defines of the register
numbers such that they match the names that GDB uses in its output,
i.e. FISEG_REGNUM instead of FCS_REGNUM, etc.

   Essentially, I see two outstanding questions remaining:

   - How should i386 targets handle the x86 FPU's 80-bit float type?  How
     can we make sure that hosts capable of handling it properly don't
     perform lossy conversions?

I still have a feeling that I don't understand the issues fully.  The
fact that the `free pascal compiler' uses 80-bit floats instead of
padded 96-bit floats complicates matters a bit.

   - What format should the output from "info float" take?  (Actually, it
     sounds like this is pretty much resolved.)

I have rewritten my implementation of "info float" to match the layout
I suggested last week.  I'll post a new patch next weekend, I have to
isolate the patch from some further changes I made, and want to test
it before submitting it.  Checking this in would give people a chance
at loooking at the layout, and any further changes to the layout can
be made without too much trouble.

   Notably missing from this list are any other questions about tm-i386.h
   as it stands.  Am I correct in thinking that the other x86 port
   maintainers think it's basically sane?

Yes.  For the Hurd the only things I have to define in tm-i386gnu.h
are Mach/Hurd specific.

   (Again, I'm excluding issues related to `long double'; I do expect
   folks to retain their own definitions for coping with that.)

I think we should try to unify those too, but that might be done later.

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]