On that hardware, at least, the user-space visible FPSCR value is indeed 0x000800000. Execution of the 'frchg' insn either doesn't trap, or the trap is caught by the kernel and emulated. I think it is not being emulated because CONFIG_SH_FPU_EMU is not set.
The comment at the top of arch/sh/kernel/cpu/sh4/fpu.c: https://elixir.bootlin.com/linux/latest/source/arch/sh/kernel/cpu/sh4/fpu.c says that on "some SH4 implementations" executing frchg with the FPSCR.PR bit set causes a trap; the "SH-4 Software Manual" says it is "undefined_operation()" which I think means "implementation could do anything" (though the manual doesn't clearly define its terms here). The kernel code in fpu.c carefully sets the FPSCR value to clear the PR bit before performing the frchg instruction. My best guess is that this is a glibc bug, where its getcontext etc implementations should be doing the same set-fpscr-first work that the kernel code is doing, and so the glibc code happens to work OK on implementations like the SH7785 that seem to not trap here, but will fail on whatever the SH4 variants are that do trap (as well as on QEMU). But this needs an SH4 expert to clarify (for instance I might well have misread the kernel code and maybe it does trap-and-emulate here so that userspace can rely on the frchg behaviour with FPSCR.PR=1 ?). Is there somebody we can ask for clarification on what the defined behaviour of the architecture is here and what the impdef behaviour of the 7750/7751/7785 happen to be ? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title: autogen crashes on qemu-sh4-user after 61dedf2af7 Status in QEMU: Confirmed Bug description: Running "autogen --help" crashes on qemu-sh4-user with: (sid-sh4-sbuild)root@nofan:/# autogen --help Unhandled trap: 0x180 pc=0xf64dd2de sr=0x00000000 pr=0xf63b9c74 fpscr=0x00080000 spc=0x00000000 ssr=0x00000000 gbr=0xf61102a8 vbr=0x00000000 sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf64dd2a0 fpul=0x00000003 r0=0xf6fc1320 r1=0x00000000 r2=0xffff5dc4 r3=0xf67bfb50 r4=0xf6fc1230 r5=0xf6fc141c r6=0x000003ff r7=0x00000000 r8=0x00000004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 r12=0xf63e2258 r13=0xf63eae1c r14=0x00000804 r15=0xf6fc1220 r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 (sid-sh4-sbuild)root@nofan:/# Bi-secting found this commit to be the culprit: 61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit commit 61dedf2af79fb5866dc7a0f972093682f2185e17 Author: Richard Henderson <r...@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 <aurel...@aurel32.net> Signed-off-by: Richard Henderson <r...@twiddle.net> Message-Id: <20170718200255.31647-26-...@twiddle.net> Signed-off-by: Aurelien Jarno <aurel...@aurel32.net> :040000 040000 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1796520/+subscriptions