[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
Thanks Peter and Richard for the quick patch. It works for me. -- 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
Just posted https://patchew.org/QEMU/20190822131534.16602-1-peter.mayd...@linaro.org/ which is basically RTH's hack from #8 with a big pile of commentary and commit message... -- 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
The test for v8m magic return addresses is not too loose -- see the v8M pseudocode IsReturn(). Architecturally the whole range of these values is special, even though in fact the exception return address encoding currently doesn't use all the bits that are reserved in this manner. I would prefer not to unset ARM_FEATURE_M_SECURITY if we can avoid it. We should definitely not allow guest code to be loaded at weird addresses in linux-user mode, I agree. -- 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
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 0x7ff, 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
** Changed in: qemu Status: New => Confirmed -- 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
** Attachment added: "qemu trace at -O2" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283732/+files/2822-1.trace.O2 -- 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
** Attachment added: "qemu trace at -Os" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283731/+files/2822-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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
** Attachment added: "executable at -O2" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283730/+files/2822-1.exe.O2 -- 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
** Attachment added: "executable at -Os" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283729/+files/2822-1.exe.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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
** Attachment added: "asm at -O2" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283728/+files/2822-1.s.O2 -- 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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
** Attachment added: "asm at -Os" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283727/+files/2822-1.s.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= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06= R07=fffeaf80 R08= R09= R10=00019dbc R11= R12=00f0 R13=fffeaf58 R14=81f3 R15=fffeaf5c XPSR=6100 -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/2822-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 ./2822-1.exe.Os To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1840922/+subscriptions
