Re: Unifying the x86 FPU register sets

[Jim Blandy <jimb at cygnus dot com>]

>    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.
> 
> Although initially I thought I needed to use different register sizes
> to implement things for exactly that format, I now see that I don't
> need that.  The reserved bits are exactly in the right place to treat
> it as an array of 32-bit values.  Only the code segment and opcode
> registers need to be treated in a different way, as you did on the
> Linux side.

Okay, sounds great then.

> A remaining issue is what we do with the reserved bits?  From looking
> at your code, it seems that you allow the user to modify the reserved
> bits (except for the reserved bit in the opcode word).  Is that a
> sensible thing to do?

I think we need to maintain a distinction between the GDB register
file and the structure the OS uses to exchange FPU state with the
debugger.  For GDB's register file, those are 16-bit registers,
zero-extended to make a 32-bit value.  (That should be stated in the
header file; I'll fix that.)  For the OS structure, it's up to the OS
to specify what those fields mean, and it's up to the OS-specific code
in GDB to do the right thing with the register file.  If some future
OS decides to put new registers there, then we should map them off to
new GDB registers.

This distinction isn't just pedantic, either --- the new SSE FXSAVE /
FXRSTOR instructions save state in a different format, incompatible
with FSAVE and FRSTOR, so either the OS interfaces will be changing,
or the old ones will be emulated by code which changes from day to
day.

I'm curious to see what Linux decides to do with the P-III support.  I
haven't looked at the Linux kernel patches yet to determine what new
ptrace interface they propose.  (Maybe I should post to the Linux
kernel mailing list.  Ooh boy.)