Re: Unifying the x86 FPU register sets

[Jim Blandy <jimb at cygnus dot com>]

>   Jim> The instruction (code) segment and offset are $fcs and $fcoff.
>   Jim> The data operand       segment and offset are $fds and $fdoff.
> 
> I suggest $fcseg and $fcoff, $fdseg and $fdoff, instead.  People who
> work a lot with seg:off pairs will recofnise `seg', but not `s'.

I prefer those names, too.  I'm waiting to see what J.T. thinks of
them.


>   Jim> We could make the control registers (except $fdoff and $fcoff)
>   Jim> sixteen-bit values.  But that makes more work for platforms that do
>   Jim> use FSAVE's 32-bit format; I assume those are the majority.
> 
> AFAIK, FSAVE does use 32 bits to store the control, status and tag
> words, but the high 16 bits are undefined.  Isn't it dangerous to copy
> all 32 bits to GDB's structures?  The DJGPP version doesn't copy the
> high 16 bits from the buffer stored by FSAVE; if other platforms do
> that as well, we already have, in effect, 16-bit control registers.
>
>   Mark> For now, GDB on the Hurd will happily display what's in the
>   Mark> reserved bits that follow the control, status, and tag word
>   Mark> and the operand pointer segment selector in the data structure
>   Mark> used by FSAVE and FRESTOR
> 
> I don't think this is right.  A user should see only the bits that are
> defined by the CPU spec.  For all we know, the rest might be random
> junk.

I agree.  After Mark's note, I changed the comment in tm-i386.h to read:

    /* All of these control registers are sixteen bits long (at most) in
       the FPU, but are zero-extended to thirty-two bits in GDB's register
       file.  This makes it easier to compute the size of the control
       register file, and somewhat easier to convert to and from the FSAVE
       instruction's 32-bit format.  */
    #define FIRST_FPU_CTRL_REGNUM 24
    #define FCTRL_REGNUM 24	        /* FPU control word */

    ...

>   Jim> [...] the new SSE FXSAVE and FXRSTOR instructions save state in
>   Jim> a different format, incompatible with FSAVE and FRSTOR, so
>   Jim> either the OS interfaces will be changing, or the old ones will
>   Jim> be emulated by code which changes from day to day.
> 
> There's another possibility: to use FXSAVE/FXRSTOR only for commands
> that handle the SSE XMMi registers, and leave the current code for the
> rest.  That way, we don't need to bother about reconciling the two
> formats.

On most targets, GDB has no control over how the registers are saved.
The OS just gives you whatever it pleases.  My point was that the
formats dictated to many of the targets by their kernels are likely to
be changing soon, so it's not worth much energy to tweak GDB's
register file to match any particular format exactly.


>   Jim> I'm curious what Linux decides to do with the P-III support.
> 
> I'm confused--why is this relevant?  Are you talking about changes
> that could affect how ptrace lays out the FP registers?  If not, what
> do we care about Linux support of Pentium III?

It was just a personal comment.  Linux's behavior should be handled by
the Linux code, so it doesn't have any direct bearing on the present
discussion, but I'm the Linux port maintainer, so I care.  At present,
Linux's ptrace doesn't give you any access to the SSE state.  Since
GDB is one of ptrace's most important clients, it's plausible that I
might end up writing the kernel patch for it.  I'm trying to figure
out how other Unices are dealing with this, so I can avoid introducing
needless diversity.