[PATCH] sh4: ensure FPSCR.PR==0 when executing FRCHG [BZ #27543]

John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de
Tue Jan 7 15:41:18 GMT 2025


Hi Adhemerval,

On Tue, 2025-01-07 at 12:10 -0300, Adhemerval Zanella Netto wrote:
> 
> On 03/01/25 16:23, mirabilos wrote:
> > 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 <tg@debian.org>
> > Reviewed-by: Oleg Endo <olegendo@gcc.gnu.org>
> > Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> > ---
> >  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(+)
> 
> The patch does not apply from patchwork, but I could apply it manually.
> 
> Besides it, LGTM although I don't have a working hardware to actually
> test it (and qemu-sh4-static shows a failure, setjmp/tst-setjmp-fp). 

Does the failure show before or after applying the patch?

For me, the patch fixes the problem that programs like debfoster which
will trigger a trap when run in an Debian unstable sh4 chroot without a
patched glibc:

(unstable-sh4-sbuild)root@adams:/# debfoster -f
Unhandled trap: 0x180
pc=0x2b3a807e sr=0x00000100 pr=0x2b3095da fpscr=0x00080000
spc=0x00000000 ssr=0x00000000 gbr=0x2b2fe200 vbr=0x00000000
sgr=0x00000000 dbr=0x00000000 delayed_pc=0x2b3a8040 fpul=0x00000000
r0=0x2b2ab8cc r1=0x00000000 r2=0xffffb8c6 r3=0x2b2efe78
r4=0x2b2ab7dc r5=0x2b2ab9b8 r6=0x2b34056c r7=0x00000000
r8=0x2b35f15c r9=0x00000021 r10=0x00000000 r11=0x00001000
r12=0x2b340250 r13=0x00000100 r14=0x2b35f158 r15=0x2b2ab70c
r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000
r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000
(unstable-sh4-sbuild)root@adams:/#

Since debfoster [1] relies on libgc, it might be an issue with libgc on
qemu-sh4-static that triggers the issue.

Adrian

> [1] https://salsa.debian.org/debian/debfoster/-/tree/debian/latest/debian?ref_type=heads

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


More information about the Libc-alpha mailing list