Program aborted when calling m5ops function in SE mode.

[4lex49]

Hi! Gem5 beginner here.
I am trying to get gem5 to output m5.stats (cache miss rate) of a ROI in the simulation code. Following the documentation M5ops, I used m5ops and wrote the simulated code like this:

//testProc.c
#include <stdio.h>
#include "gem5/m5ops.h"

int main() {
    //read some files to prepare
    printf("Preparation completed!\n);
    m5_dump_reset_stats(0,0);
    //ROI code
    m5_dump_stats(0,0);
    return 0;
}

Using SE mode and ARM arch (on X86 host) of Gem5, I called command:

sudo ./build/ARM/gem5.debug ./configs/deprecated/example/se.py --cmd=/path/to/testProc

But the simulated code aborted after printing "Preparation completed!". Here is the full output of gem5:

gem5 Simulator System.  https://www.gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 version 23.1.0.0
gem5 compiled Aug  1 2024 17:44:37
gem5 started Sep  8 2024 16:58:29
gem5 executing on ubuntu, pid 32654
command line: ./build/ARM/gem5.opt ./configs/deprecated/example/se.py --cmd=./test_ops/testProc

warn: The se.py script is deprecated. It will be removed in future releases of  gem5.
Global frequency set at 1000000000000 ticks per second
warn: No dot file generated. Please install pydot to generate the dot file and pdf.
src/mem/dram_interface.cc:692: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
src/base/statistics.hh:279: warn: One of the stats is a legacy stat. Legacy stat is a stat that does not belong to any statistics::Group. Legacy stat is deprecated.
system.remote_gdb: Listening for connections on port 7000
**** REAL SIMULATION ****
src/sim/simulate.cc:199: info: Entering event queue @ 0.  Starting simulation...
src/sim/mem_state.cc:448: info: Increasing stack size by one page.
Preparation completed!
src/arch/arm/insts/pseudo.cc:173: warn: 	instruction 'cdp' unimplemented
src/arch/arm/faults.cc:799: panic: Attempted to execute unknown instruction (inst 0x0000deff)
Memory Usage: 707048 KBytes
Program aborted at tick 5380000
--- BEGIN LIBC BACKTRACE ---
./build/ARM/gem5.opt(_ZN4gem515print_backtraceEv+0x2c)[0x55b9805c8a5c]
./build/ARM/gem5.opt(_ZN4gem512abortHandlerEi+0x4a)[0x55b9805ee32a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f2407922980]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f2405e0ae87]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f2405e0c7f1]
./build/ARM/gem5.opt(+0xe0297f)[0x55b98031d97f]
./build/ARM/gem5.opt(_ZN4gem56ArmISA20UndefinedInstruction6invokeEPNS_13ThreadContextERKNS_14RefCountingPtrINS_10StaticInstEEE+0x10d)[0x55b9806df29d]
./build/ARM/gem5.opt(_ZN4gem513BaseSimpleCPU9advancePCERKSt10shared_ptrINS_9FaultBaseEE+0xb2)[0x55b981bdf832]
./build/ARM/gem5.opt(_ZN4gem515AtomicSimpleCPU4tickEv+0x315)[0x55b981bc7175]
./build/ARM/gem5.opt(_ZN4gem510EventQueue10serviceOneEv+0xad)[0x55b9805df9ad]
./build/ARM/gem5.opt(_ZN4gem59doSimLoopEPNS_10EventQueueE+0x88)[0x55b980609768]
./build/ARM/gem5.opt(_ZN4gem58simulateEm+0x28b)[0x55b980609e0b]
./build/ARM/gem5.opt(+0x24dc13e)[0x55b9819f713e]
./build/ARM/gem5.opt(+0xde80cc)[0x55b9803030cc]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyCFunction_Call+0x96)[0x7f2407d42736]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x76e0)[0x7f2407cb3b20]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f2407caaa0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f2407cab0fc]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f2407cb1303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17a803)[0x7f2407ca9803]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c2be)[0x7f2407cab2be]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f2407cb1303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f2407caaa0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c0fc)[0x7f2407cab0fc]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f2407cb1303]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17ba0f)[0x7f2407caaa0f]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCodeEx+0x3e)[0x7f2407cab4ce]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(PyEval_EvalCode+0x1b)[0x7f2407cac24b]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x18855d)[0x7f2407cb755d]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyCFunction_FastCallDict+0x1bb)[0x7f2407d4253b]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(+0x17c1ec)[0x7f2407cab1ec]
/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0(_PyEval_EvalFrameDefault+0x4ec3)[0x7f2407cb1303]
--- END LIBC BACKTRACE ---
For more info on how to address this issue, please visit https://www.gem5.org/documentation/general_docs/common-errors/ 

Though there is a panic of unknown inst(0x0000deff), I tried remote-gdb(gdb-multiarch) to debug and found out that the program actually aborted after calling <m5_dump_reset_stats>. It seems that the m5 op (ee420110 mcr 1, 2, r0, cr2, cr0, {0}) caused the error.

More attempts show that all m5ops(including m5_sum, m5_reset_stats) seem to trigger this problem, while not calling m5ops will run normally until the end of the program.

How can I handle this? Or is there any other way for me to monitor the ROI code? Any information on this would be very helpful.

Here are some additional information:

I builtlibm5.a with scons and make the simulated target by arm-linux-gnueabihf:

TARGET_ISA=arm

GEM5_HOME=/path/to/gem5
$(info   GEM5_HOME is $(GEM5_HOME))

GCC=arm-linux-gnueabihf-gcc

CFLAGS=-I$(GEM5_HOME)/include

LDFLAGS=-L$(GEM5_HOME)/util/m5/build/$(TARGET_ISA)/out -lm5

OBJECTS= testProc

all: testProc

testProc:
        $(GCC) -o $(OBJECTS) testProc.c $(CFLAGS) $(LDFLAGS) -static -g

clean:
        rm -f $(OBJECTS)

[Andres-Marin]

Hi, I have a similar issue and I have not figured out yet what is wrong.

[powerjg]

@giactra are you aware of any problems with the implementation of the instruction version of m5ops for Arm in SE mode?

[4lex49]

Thanks for the comments! I have no idea about the bug. But for those who have the same problem as me, that is, calling m5ops for ARM simulation on X86 host, here may be an alternative solution:
Instead of including m5ops.h, include the following code in the simulation program:

inline void dump_reset_stats(){
    __asm__ __volatile__ (
        ".inst 0xf04f0200\n"   //mov.w r2, #0
	".inst 0xf04f0300\n"   //mov.w r3, #0
	".inst 0xf04f0000\n"   //mov.w r0, #0
	".inst 0xf04f0100\n"   //mov.w r1, #0
	".inst 0xee420110\n"   // m5_dump_reset_stats function call
	:::"r0","r1","r2","r3"
    );
}

inline void dump_stats(){
    __asm__ __volatile__ (
        ".inst 0xf04f0200\n"
	".inst 0xf04f0300\n"
	".inst 0xf04f0000\n"
	".inst 0xf04f0100\n"
	".inst 0xee410110\n" // m5_dump_stats function call
	:::"r0","r1","r2","r3"
    );
}

These functions call gem5ops directly via inline assembly code, and it does work for me. I'm not good at assembly code, so if there are any problems please feel free to point them out.
If you want to cover more m5ops, or on other architectures, referring to definition of m5ops, assembly macros and here may be helpful.

Does this mean that there may be a problem with the compatibility of the cross compiler, or that something wrong with the function call return address? At least the calls and responses of m5ops are fine.

[giactra]

Thanks for providing this info. I will look into this now

[giactra]

What I believe is happening is that you have an A32 implementation of the m5 function (you linked to it) but your CPU is actually in thumb mode so the instruction gets wrongly decoded. As a workaround you should add -marm to your CFLAGS to force A32 compilation.... We might consider doing something different in the long run...

[4lex49]

Thank you so much for your reply! By adding -marm to CFLAGS, m5ops now works well. I think I should learn more about ARM Instruction Sets and Gem5...