Re: [RFA]: Convert the last FP opcode saved by FSAVE into a full opcode

[Eli Zaretskii <eliz@delorie.com>]

> From: Mark Kettenis <kettenis@wins.uva.nl>
> Date: 09 Feb 2001 14:27:02 +0100
> 
> Hmm, right now, in i387-tdep.c:i387_float_info() we have the following
> code:
> 
>   printf_filtered ("Opcode:              %s\n",
>                    local_hex_string_custom (fop ? (fop | 0xd800) : 0, "04"));
> 
> So I don't understand why you're missing those bits in the output of
> "info float".  I guess that you want "p $fop" to print the full opcode
> too (without the missing bits).

That's one reason, yes.

Also, what about the platforms/configurations which don't use CLI?  Do
they all go through i387_float_info and printf_filtered?

> I'm also somewhat concerned
> about consistency between the various x86 targets.  If we apply your
> patch, targets that don't use the functions from i387-nat.c still
> won't include the extra bits.

We could fix those targets as well, can't we?

> That said, I'm open to discussion.  If other x86 maintainers prefer $fop to
> contain the full opcode your change would in principle be fine with
> me.

Yes, please speak up your minds.

> But even then, there still might be something wrong with your
> patch.  On UNIX, the kernel typically returns a dummy FSAVE/FXSAVE
> state if the program didn't use the FPU (yet), where the opcode is all
> zeroes.  In that case I don't think that we want to add the 0xd800.

I think my patch explicitly guards agains this.  Here's the relevant
snippet:

+	      if (val)
+		val |= 0xd800;

In other words, if the opcode is zero, it is left unaltered, exactly
like in i387-tdep.c.