Unicorn: Why is it always MIPS

[Arusekk]

$ strace -enone -es=SEGV -k python3.13 -m sphinx -b doctest docs/source docs/build/doctest docs/source/elf/corefile.rst
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(temp_load+0x95) [0x870635]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(tcg_gen_code_mipsel+0x1ed8) [0x879638]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(tb_gen_code_mipsel+0x159) [0x8a0f69]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(cpu_exec_mipsel+0x507) [0x883bf7]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(resume_all_vcpus_mipsel+0x99) [0x848c49]
 > /home/arusekk/.local/lib/python3/site-packages/unicorn/lib/libunicorn.so.2(uc_emu_start+0x10d) [0x3c4dad]
 > /usr/lib64/libffi.so.8.2.0() [0xa056]
 > /usr/lib64/libffi.so.8.2.0() [0x8ff1]
 > /usr/lib64/libffi.so.8.2.0(ffi_call+0x13e) [0x990e]
 > /usr/lib/python3.13/lib-dynload/_ctypes.cpython-313-x86_64-linux-gnu.so() [0x1d0fe]
 > /usr/lib/python3.13/lib-dynload/_ctypes.cpython-313-x86_64-linux-gnu.so() [0x15b0c]
 > /usr/lib64/libpython3.13.so.1.0(_PyObject_MakeTpCall+0x84) [0x25d684]
 > /usr/lib64/libpython3.13.so.1.0(_PyEval_EvalFrameDefault+0x841e) [0x3ec33e]
 > /usr/lib64/libpython3.13.so.1.0() [0x25f555]
 > /usr/lib64/libpython3.13.so.1.0() [0x25f7cd]
 > /usr/lib64/libpython3.13.so.1.0() [0x30f5fc]
 > /usr/lib64/libpython3.13.so.1.0() [0x30605a]
 > /usr/lib64/libpython3.13.so.1.0(_PyObject_MakeTpCall+0x84) [0x25d684]
 > /usr/lib64/libpython3.13.so.1.0(_PyEval_EvalFrameDefault+0x2156) [0x3e6076]
 > /usr/lib64/libpython3.13.so.1.0(PyEval_EvalCode+0x165) [0x3f2f95]
 > /usr/lib64/libpython3.13.so.1.0() [0x3dd891]
 > /usr/lib64/libpython3.13.so.1.0(_PyEval_EvalFrameDefault+0x54e1) [0x3e9401]
 > /usr/lib64/libpython3.13.so.1.0(PyEval_EvalCode+0x165) [0x3f2f95]
 > /usr/lib64/libpython3.13.so.1.0() [0x3dd891]
 > /usr/lib64/libpython3.13.so.1.0() [0x2c8301]
 > /usr/lib64/libpython3.13.so.1.0(PyObject_Vectorcall+0x5a) [0x25d94a]
 > /usr/lib64/libpython3.13.so.1.0(_PyEval_EvalFrameDefault+0x2156) [0x3e6076]
 > /usr/lib64/libpython3.13.so.1.0() [0x4954e9]
 > /usr/lib64/libpython3.13.so.1.0(Py_RunMain+0x5ba) [0x495dca]
 > /usr/lib64/libpython3.13.so.1.0(Py_BytesMain+0x56) [0x496a46]
 > /lib64/libc.so.6() [0x2760b]
 > /lib64/libc.so.6(__libc_start_main+0x8a) [0x276ba]
 > /usr/bin/python3.13(_start+0x25) [0x735]
+++ killed by SIGSEGV +++
[1]    11180 segmentation fault  strace -enone -es=SEGV -k python3.13 -m sphinx -b doctest docs/source/elf/corefile.rst

[Arusekk]

This is still caused by the same problem with uninitialized delay slot: unicorn-engine/unicorn#2134

[wtdcode]

Answering the title: Why is it always MIPS?

Because QEMU does not have previous block delay slot information when executing current block, so more architectural hack needs to be implemented.