Re: [PATCH] Fix returning floating points values for x86

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Wed, 11 Jul 2001 19:12:58 +0300
   From: "Eli Zaretskii" <eliz@is.elta.co.il>

   > Date: Wed, 11 Jul 2001 10:49:16 +0200
   > From: Mark Kettenis <kettenis@wins.uva.nl>
   > 
   > 	* i386-tdep.c (i386_extract_return_value): "Fix" comment.
   > 	(i386_store_return_value): Frob FPU status and tag word to make
   > 	sure the return value is the only value on the FPU stack.

   Mark, could you please say a few words about the problem that this
   solves, and why is this the right solution?  I admit I don't
   understand it, and the comment about st(0) scared me a bit: it's
   certainly _not_ true, in general, that st(0) is always FP0_REGNUM.

With pleasure.  The problem the patch solves is returning from a
function with the GDB `return' command, or more specifically returning
from a function that has a floating point return value.

The System V ABI specifies that floating point return values appear on
the top of the floating point register stack, i.e. in %st(0).
Furthermore is specifies that %st(0) muts be empty before entry to a
function, and that %st(1) through %st(0) (which are called
floating-point scratch registers in the System V ABI) must be empty
before entry and upon exit from a function.

If we suppose that the FPU starts out in a freshly initialized state,
with all registers empty and TOP set to 0, this means that we'll
always end up with storing return values in the hardware register 7,
i.e. with TOP set to 7.  So it makes sense to reset the FPU to that
state in i386_store_return_value.  What value we choose for TOP is in
principle irrelevant since FP0_REGNO always refers to %st(0).  But we
must mark the right register as valid (and all others as empty) in the
tag word, and here the value of TOP does matter.  If we don't mark the
right register as valid, the caller of the function won't be able to
pop the return value from the stack, and if we don't mark the other
registers as empty we might trigger an unwanted stack overflow.

I was obviously a bit confused about %st(0) being FP0_REGNO or not.
The comment that worries you was the result of that.  I will fix the
comments.

Mark