If the bit is not 0, the operations FRCHG and FSCHG are undefined and cause a trap; qemu now checks for this as well, so we set it to 0 temporarily and restore the old value in getcontext afterwards (setcontext/swapcontext already do so). From the discussion in the bugreport, this can probably be optimised in one place but none of the people involved are SH4 assembly experts, this patch is field-tested, and it’s not a code path run often. The other question, what happens if a signal occurs while the bit is temporarily 0, is also still unsolved, but to fix that a kernel change is most likely needed; this patch changes a certain trap on many CPUs for a hard-to-get trap in a signal handler if a signal is delivered during the few instructions the PR bit is temporarily set to 0, so it’s not a regression for most users. See BZ and https://bugs.launchpad.net/qemu/+bug/1796520 for related discussion, references and review comments. Signed-off-by: mirabilos Reviewed-by: Oleg Endo Tested-by: John Paul Adrian Glaubitz --- sysdeps/unix/sysv/linux/sh/sh4/getcontext.S | 6 ++++++ sysdeps/unix/sysv/linux/sh/sh4/setcontext.S | 2 ++ sysdeps/unix/sysv/linux/sh/sh4/swapcontext.S | 2 ++ 3 files changed, 10 insertions(+)