[Qemu-devel] [Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7

[Peter Maydell]

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 <address@hidden>
  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 <address@hidden>
      Signed-off-by: Richard Henderson <address@hidden>
      Message-Id: <address@hidden>
      Signed-off-by: Aurelien Jarno <address@hidden>

  :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