Comment 4 for bug 1796520

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 ?