** Attachment added: "qemu trace at -Os" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283731/+files/20000822-1.trace.Os
-- 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: New 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
