Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Fix returning floating points values for x86
Date: Wed, 11 Jul 2001 13:28:00 -0000	[thread overview]
Message-ID: <200107112028.f6BKSOS26755@delius.kettenis.local> (raw)
In-Reply-To: <1438-Wed11Jul2001191258+0300-eliz@is.elta.co.il>

   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


  reply	other threads:[~2001-07-11 13:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-11  1:49 Mark Kettenis
2001-07-11  9:13 ` Eli Zaretskii
2001-07-11 13:28   ` Mark Kettenis [this message]
2001-07-12  0:00     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200107112028.f6BKSOS26755@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox