linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Liu Yu <yu.liu@freescale.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	Shan Hai <shan.hai@windriver.com>
Subject: Re: [PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation
Date: Fri, 22 Nov 2013 16:34:04 -0600	[thread overview]
Message-ID: <1385159644.1403.532.camel@snotra.buserror.net> (raw)
In-Reply-To: <Pine.LNX.4.64.1311041651390.4290@digraph.polyomino.org.uk>

On Mon, 2013-11-04 at 16:52 +0000, Joseph S. Myers wrote:
> From: Joseph Myers <joseph@codesourcery.com>
> 
> The e500 SPE floating-point emulation code clears existing exceptions
> (__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the
> emulated operation.  However, these exception bits are the "sticky",
> cumulative exception bits, and should only be cleared by the user
> program setting SPEFSCR, not implicitly by any floating-point
> instruction (whether executed purely by the hardware or emulated).
> The spurious clearing of these bits shows up as missing exceptions in
> glibc testing.
> 
> Fixing this, however, is not as simple as just not clearing the bits,
> because while the bits may be from previous floating-point operations
> (in which case they should not be cleared), the processor can also set
> the sticky bits itself before the interrupt for an exception occurs,
> and this can happen in cases when IEEE 754 semantics are that the
> sticky bit should not be set.  Specifically, the "invalid" sticky bit
> is set in various cases with non-finite operands, where IEEE 754
> semantics do not involve raising such an exception, and the
> "underflow" sticky bit is set in cases of exact underflow, whereas
> IEEE 754 semantics are that this flag is set only for inexact
> underflow.  Thus, for correct emulation the kernel needs to know the
> setting of these two sticky bits before the instruction being
> emulated.
> 
> When a floating-point operation raises an exception, the kernel can
> note the state of the sticky bits immediately afterwards.  Some
> <fenv.h> functions that affect the state of these bits, such as
> fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and
> PR_SET_FPEXC anyway, and so it is natural to record the state of those
> bits during that call into the kernel and so avoid any need for a
> separate call into the kernel to inform it of a change to those bits.
> Thus, the interface I chose to use (in this patch and the glibc port)
> is that one of those prctl calls must be made after any userspace
> change to those sticky bits, other than through a floating-point
> operation that traps into the kernel anyway.

This sounds like an incompatible change to userspace API.  What about
older glibc?  What about user code that directly manipulates these bits
rather than going through libc, or uses a libc other than glibc?  Where
is this API requirement documented?

I think the impact of this could be reduced by using this mechanism only
to clear bits, rather than set them.  That is, if the exception bit is
unset, don't set it just because it's set in spefscr_last -- but if it's
not set in spefscr_last, and the emulation code doesn't want to set it,
then clear it.

Are there any cases where the exception bit can be set without the
kernel taking a trap, or is userspace manipulation limited to clearing
the bits?

-Scott

  reply	other threads:[~2013-11-22 22:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 16:50 [PATCH 0/6] powerpc/math-emu: e500 SPE float emulation fixes Joseph S. Myers
2013-11-04 16:52 ` [PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation Joseph S. Myers
2013-11-22 22:34   ` Scott Wood [this message]
2013-11-23  1:22     ` Joseph S. Myers
2013-12-07  0:32       ` Scott Wood
2013-12-07  0:48         ` questions: second of the 2 pcie controllers does not scan the bus Ruchika
2013-12-07 13:26           ` Ruchika
2013-12-09 22:50           ` Scott Wood
2013-12-10 23:07         ` [PATCHv2 1/6] powerpc: fix exception clearing in e500 SPE float emulation Joseph S. Myers
2013-11-04 16:53 ` [PATCH 2/6] powerpc: fix e500 SPE float rounding inexactness detection Joseph S. Myers
2013-11-04 16:53 ` [PATCH 3/6] math-emu: fix floating-point to integer unsigned saturation Joseph S. Myers
2013-11-04 16:54 ` [PATCH 4/6] math-emu: fix floating-point to integer overflow detection Joseph S. Myers
2013-11-04 16:54 ` [PATCH 5/6] powerpc: fix e500 SPE float to integer and fixed-point conversions Joseph S. Myers
2013-11-04 16:55 ` [PATCH 6/6] powerpc: fix e500 SPE float SIGFPE generation Joseph S. Myers
2013-11-11 14:29 ` Ping Re: [PATCH 0/6] powerpc/math-emu: e500 SPE float emulation fixes Joseph S. Myers
2013-11-18 14:54   ` Ping^2 " Joseph S. Myers
2013-11-18 19:07     ` Scott Wood

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=1385159644.1403.532.camel@snotra.buserror.net \
    --to=scottwood@freescale.com \
    --cc=joseph@codesourcery.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=shan.hai@windriver.com \
    --cc=yu.liu@freescale.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;
as well as URLs for NNTP newsgroup(s).