[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

[Richard Henderson]

This happens because we're applying a loose test for the v8m magic
exception return address.

There are two possible fixes for this, and perhaps we should
apply both of them:

(1) Unset ARM_FEATURE_M_SECURITY for arm-linux-user.
    This would disable the FNC_RETURN_MIN_MAGIC test,
    which, unlike EXC_RETURN_MIN_MAGIC, is not protected
    by a condition that linux-user cannot satisfy (Handler mode).

(2) Limit the address space to 0x7ffffff, the normal end of
    write-back cached ram.  Since M-profile doesn't have an MMU,
    this would make linux-user addresses more like what we'd see
    running the same test under system mode.

** Patch added: "Hack to work around the problem; not a proper solution."
   
https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283854/+files/z.patch

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1840922

Title:
  qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

Status in QEMU:
  Confirmed

Bug description:
  Hi,

  While experimenting with running the GCC testsuite with cortex-m33 as target 
(to exercise v8-m code), I came across this failure:
  qemu: unhandled CPU exception 0x8 - aborting
  R00=fffeaf58 R01=fffeaf58 R02=00000000 R03=fffeaf5d
  R04=fffeaf5c R05=fffeaf9c R06=00000000 R07=fffeaf80
  R08=00000000 R09=00000000 R10=00019dbc R11=00000000
  R12=000000f0 R13=fffeaf58 R14=000081f3 R15=fffeaf5c
  XPSR=61000000 -ZC- T NS priv-thread
  qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6033c908

  I'm using arm-eabi-gcc, so it targets bare-metal, not linux.

  The testcase is GCC's
  gcc/testsuite/gcc.c-torture/execute/20000822-1.c; it works when
  compiled at -O2, but crashes when compiled at -Os. The test uses
  nested functions, so it creates a trampoline on the stack, whose
  address may be a problem. But since the stack address seems to be in
  the same range in the O2 and Os cases, it's not that clear.

  I'm attaching the C source, asm, binary executables and qemu traces
  with in_asm,cpu.

  I execute the binaries with:
  qemu-arm --cpu cortex-m33  ./20000822-1.exe.Os

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions