[Bug ports/27543] New: Inconsistent behavior when handling FPSCR on SH

[Bug ports/27543] New: Inconsistent behavior when handling FPSCR on SH

[glaubitz at physik dot fu-berlin.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=27543

            Bug ID: 27543
           Summary: Inconsistent behavior when handling FPSCR on SH
           Product: glibc
           Version: 2.31
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ports
          Assignee: unassigned at sourceware dot org
          Reporter: glaubitz at physik dot fu-berlin.de
                CC: adhemerval.zanella at linaro dot org, carlos at redhat dot com,
                    jrtc27 at jrtc27 dot com, peter.maydell at linaro dot org
  Target Milestone: ---
            Target: sh*-*-*

Quite some time ago, I reported a regression in qemu-user on sh4 which caused
an unhandled trap when running programs like autogen on qemu-sh4 while they
worked fine on real hardware.

Bi-secting the problem lead to this change in qemu:

61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit
commit 61dedf2af79fb5866dc7a0f972093682f2185e17
Author: Richard Henderson <rth@twiddle.net>
Date: Tue Jul 18 10:02:50 2017 -1000

    target/sh4: Add missing FPSCR.PR == 0 checks

    Both frchg and fschg require PR == 0, otherwise undefined_operation.

    Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
    Signed-off-by: Richard Henderson <rth@twiddle.net>
    Message-Id: <20170718200255.31647-26-rth@twiddle.net>
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>

According to Peter Maydell, however, the behavior of qemu here is according to
spec and he suspects that glibc is handling the setting of the FPSCR.PR bit
incorrectly.

To quote him from the bug report:

==============================================================================

I can reproduce this bug, but I'm not sure what QEMU is doing wrong. Looking at
the "SH4 Software Manual", it definitely says that if the FPSCR.PR bit is 0
then the 'frchg' and 'fschg' instructions should both trap.

The 'frchg' that autogen is hitting is the one in glibc's "getcontext"
implementation:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sh/sh4/getcontext.S;hb=b6d2c4475d5abc05dd009575b90556bdd3c78ad0#l70

QEMU linux-user mode runs with FPSCR=0x000800000, which is "FPSCR.PR == 1", ie
"double precision". This seems to match what the kernel has for its FPSCR_INIT
value.

==============================================================================

So maybe glibc should handle the FPSCR.PR bit the same way the kernel does?

> [1] https://bugs.launchpad.net/qemu/+bug/1796520

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/27543] Inconsistent behavior when handling FPSCR on SH

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27543

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Please don't use the ports component in Bugzilla for new bugs.  The 
component description says "obsolete component, do not file new issues 
here"; the component should only have bugs that were filed and resolved 
long ago when a separate ports repository used to be in use.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/27543] Inconsistent behavior when handling FPSCR on SH

[glaubitz at physik dot fu-berlin.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=27543

John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tg at mirbsd dot de

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/27543] Inconsistent behavior when handling FPSCR on SH

[glaubitz at physik dot fu-berlin.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=27543

--- Comment #2 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Thorsten Glaser has suggested the following patch which fixes the bug for me:

diff --git a/sysdeps/unix/sysv/linux/sh/sh4/getcontext.S
b/sysdeps/unix/sysv/linux/sh/sh4/getcontext.S
index 2545fe7870..ebe1b3fd4f 100644
--- a/sysdeps/unix/sysv/linux/sh/sh4/getcontext.S
+++ b/sysdeps/unix/sysv/linux/sh/sh4/getcontext.S
@@ -67,6 +67,8 @@ ENTRY(__getcontext)
        add     #(oFPUL+4-124),r0
        sts.l   fpul, @-r0
        sts.l   fpscr, @-r0
+       mov     #0, r6
+       lds     r6, fpscr
        frchg
        fmov.s  fr15, @-r0
        fmov.s  fr14, @-r0
@@ -101,6 +103,10 @@ ENTRY(__getcontext)
        fmov.s  fr2, @-r0
        fmov.s  fr1, @-r0
        fmov.s  fr0, @-r0
+       mov     r4, r0
+       add     #124, r0
+       add     #(oFPSCR-124), r0
+       lds.l   @r0+, fpscr
 #endif /* __SH_FPU_ANY__ */

        /* sigprocmask (SIG_BLOCK, NULL, &uc->uc_sigmask).  */
diff --git a/sysdeps/unix/sysv/linux/sh/sh4/setcontext.S
b/sysdeps/unix/sysv/linux/sh/sh4/setcontext.S
index dd523a8cdb..098a305e80 100644
--- a/sysdeps/unix/sysv/linux/sh/sh4/setcontext.S
+++ b/sysdeps/unix/sysv/linux/sh/sh4/setcontext.S
@@ -50,6 +50,8 @@ ENTRY(__setcontext)

 .Lsetcontext_restore:
 #ifdef __SH_FPU_ANY__
+       mov     #0, r9
+       lds     r9, fpscr
        mov     r8, r0
        add     #(oFR0),r0
        fmov.s  @r0+, fr0
diff --git a/sysdeps/unix/sysv/linux/sh/sh4/swapcontext.S
b/sysdeps/unix/sysv/linux/sh/sh4/swapcontext.S
index 1ff4fd612b..85cc4b1104 100644
--- a/sysdeps/unix/sysv/linux/sh/sh4/swapcontext.S
+++ b/sysdeps/unix/sysv/linux/sh/sh4/swapcontext.S
@@ -67,6 +67,8 @@ ENTRY(__swapcontext)
        add     #(oFPUL+4-124),r0
        sts.l   fpul, @-r0
        sts.l   fpscr, @-r0
+       mov     #0, r9
+       lds     r9, fpscr
        frchg
        fmov.s  fr15, @-r0
        fmov.s  fr14, @-r0

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/27543] Inconsistent behavior when handling FPSCR on SH

[glaubitz at physik dot fu-berlin.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=27543

John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/27543] Inconsistent behavior when handling FPSCR on SH

[jrtc27 at jrtc27 dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27543

--- Comment #3 from Jessica Clarke <jrtc27 at jrtc27 dot com> ---
Some comments:

1. QEMU's behaviour matches my reading of the spec
2. Linux's arch/sh/kernel/cpu/sh4/fpu.c says "Executing frchg with PR set
causes a trap on some SH4 implementations", so presumably some implementations
allow it, including the processor on your boards
3. What happens if a signal is delivered whilst FPCSR.PR is temporarily 0?
4. For __getcontext, can you use a temporary register (various ones are about
to be clobbered for the syscall arguments; r1, r2, r3, r5 and r6 all look free
to me) instead of the slightly ugly approach of loading back from the context
that was just written to?

-- 
You are receiving this mail because:
You are on the CC list for the bug.