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.
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.
Are you in a position to test what the actual hardware/real Linux kernel using for its FPSCR value when running sh4 userspace binaries ?
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: /sourceware. org/git/ ?p=glibc. git;a=blob; f=sysdeps/ unix/sysv/ linux/sh/ sh4/getcontext. S;hb=b6d2c4475d 5abc05dd009575b 90556bdd3c78ad0 #l70
https:/
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.
Are you in a position to test what the actual hardware/real Linux kernel using for its FPSCR value when running sh4 userspace binaries ?