qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
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_
I'm using arm-eabi-gcc, so it targets bare-metal, not linux.
The testcase is GCC's gcc/testsuite/
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
Changed in qemu: | |
status: | New → Confirmed |
Changed in qemu: | |
status: | Fix Committed → Fix Released |
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. MIN_MAGIC test, MIN_MAGIC, is not protected
This would disable the FNC_RETURN_
which, unlike EXC_RETURN_
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.