[RFA]: Convert the last FP opcode saved by FSAVE into a full opcode
Eli Zaretskii
eliz@delorie.com
Fri Feb 9 06:58:00 GMT 2001
> 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.
More information about the Gdb-patches
mailing list