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

Bug #1840922 reported by Christophe Lyon
8
This bug affects 1 person
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_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

Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Revision history for this message
Christophe Lyon (christophe-lyon) wrote :
Richard Henderson (rth)
Changed in qemu:
status: New → Confirmed
Revision history for this message
Richard Henderson (rth) wrote :

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.

Revision history for this message
Peter Maydell (pmaydell) wrote :

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.

Revision history for this message
Peter Maydell (pmaydell) wrote :

Just posted
https://<email address hidden>/

which is basically RTH's hack from #8 with a big pile of commentary and commit message...

Revision history for this message
Christophe Lyon (christophe-lyon) wrote :

Thanks Peter and Richard for the quick patch. It works for me.

Revision history for this message
Peter Maydell (pmaydell) wrote :

Fixed in master as commit 5e5584c89f36b, will be in the 4.2 release.

Changed in qemu:
status: Confirmed → Fix Committed
Thomas Huth (th-huth)
Changed in qemu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.