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: Unifying the x86 FPU register sets



> I can see no problems that would make it impossible to adapt the Hurd
> to use these definitions.

Groovy.

>    - If you see anything unclear or ambiguous, please say so.  Each
>      register's meaning should be completely specified.  It should be
>      completely obvious how each target should fill in the register file.
>      It won't do us any good if everybody does it slightly differently.
> 
> What's the meaning of `SIZEOF_FPU_CTRL_REGS' supposed to be?  Does it
> imply that GDB will expects its `pseudo' FP control registers to be a
> 32bit value each?  Or will we allow REGISTER_RAW_SIZE(n) for the
> control registers to be different from 4 for FIRST_FPU_CTRL_REGNUM <=
> n <= LAST_FPU_CTRL_REGNUM ?  And will we allow different values for
> different targets?  This affects the floating point status printing
> routine of course, but I think it should be possible to write it such
> that it can deal with such differences.

There's more stuff in i386-tdep.c which makes the intent clearer ---
in particular, the i386_register_raw_size table is there.  See the
URL's below.

It would certainly be possible to allow the register sizes vary from
one platform to the next, and make sure i387-tdep.c relies entirely on
the macros and tables to do its job.  But to do that, we would need to
design the macros more carefully than I have --- I don't think they're
sufficient for the job right now.  I'd rather have them be fixed.

We could make the control registers (except $fdoff and $fcoff)
sixteen-bit values.  But that makes more work for platforms that do
use FSAVE's 32-bit format; I assume those are the majority.


>    - I've got Linux working using this text, but it's still highly
>      experimental.  Please read with a critical eye.
> 
> I'll start working on Hurd support if I don't hear about objections
> from other people soon.  Could you make the Linux code available
> somehow?

Here is the full patch for all i386 architectures, including the
definitions for the raw register size arrays and such:
  http://www.cygnus.com/~jimb/jimb.i386-fp.patch

Here is my current patch for Linux:
  http://www.cygnus.com/~jimb/jimb.i386-linux-fp.patch

>    - Since there are a lot of configurations that use the register info in
>      tm-i386.h unmodified (see the diagram), and not all of those
>      platforms have maintainers participating in this discussion, we may
>      only change tm-i386.h in backwards-compatible ways.
> 
> Is this why you kept FPC_REGNUM?  It should be possible to replace
> FPC_REGNUM with FCTRL_REGNUM in all targets without breaking any of
> them, and remove FPC_REGNUM completely.

That's true.

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