qemu-system-arm segfaults on "smulbb r7, r5, r5"

Bug #1636126 reported by Roman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Invalid
Undecided
Unassigned

Bug Description

I'll attach a binary that runs fine with qemu-system-arm V2.2.0 but V2.7.0 segfaults.
By stepping through with gdb I found that the segfaults happens when executing the line "smulbb r7, r5, r5" (where r7=0x1, r5=0x12).
I'll also attach a debugger screenshot.

call and output:

/opt/qemu-system-arm -M integratorcp -cpu cortex-m3 -semihosting -nographic -monitor null -serial null -no-reboot -kernel 0MFW_SafetyFunctions_ParameteruP1_CUNIT.elf

------------ CUnit_MFW_SafetyFunctions_Parameter ------------

     CUnit - A Unit testing framework for C - Version 2.1-0
     http://cunit.sourceforge.net/

Suite: Suite_MFW_SafetyFunctions_Parameter
  Test: MFW_SafetyFunctions_Parameter_PositionLimiter ... Segmentation fault (core dumped)

Tags: qemu segfault
Revision history for this message
Roman (romanzwi000) wrote :
Revision history for this message
Roman (romanzwi000) wrote :

in the screenshot one can see the assembler line that fails

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

Hi. This command line:

/opt/qemu-system-arm -M integratorcp -cpu cortex-m3 ...

is wrong. The integratorcp board is not a Cortex-M3 and trying to stick one into it produces something that is not likely to work very well. Please can you either (a) using a board that's expected to support a Cortex-M3, like the lm3s6965evb or lm3s811evb, or (b) using the integratorcp's default CPU if that's what your guest code is supposed to run on. This sort of frankenstein combination is not supported...

That said, your problem here is that the SMULBB instruction is part of the M profile DSP extension, which is not implemented in the Cortex-M3 (it first appears in the -M4). Not UNDEFing on the DSP instructions in our Cortex-M3 model was a bug in QEMU v2.2 which we have subsequently fixed.

You should build your guest code to target the CPU you're trying to run it on.

Revision history for this message
Roman (romanzwi000) wrote :

Hi Peter!

Thank you for your help, it works fine with "-M integratprcp -cpu cortex-m4" but I might choose another board as you suggested.
I didn't have in mind that we switched to M4 instruction set.

Where do I get the information that integratorcp is not good for cortex-M3?
Or better question: where do I get information which machine is good for it?
Actually "-M help" doesn't give me any with M3 (already tried "none" and "virt" without success).
On the other hand I see all cortex variants in the output of "-M integratorcp -cpu help" so I had a good feeling about it...

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

You're right that we don't document this at all (and the board models don't have any way of restricting the set of things that '-cpu help' lists to only what they support). As a rule of thumb, for any ARM board except 'virt' don't try to use anything except the default CPU. They all model embedded boards which don't have any kind of support for unplugging and replugging CPUs.

The particular problem with trying to use cortex-m3 on the integratorcp is that there is no NVIC on the integratorcp so if you try to do anything involving the M3's interrupt controller it is likely to blow up or otherwise misbehave.

Our two M3 boards are the lm3s6965evb and lm3s811evb (they're Stellaris boards).

Revision history for this message
Roman (romanzwi000) wrote :

Tried to run cortex-M4 command on M3.

Changed in qemu:
status: New → Invalid
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.