Gem5 fails with panic: cpu stucked!!

[ZyablitskiyA]

Hello dear XiangShan Gem5 developers!
I've crafted a simple repro for a problem I encounter running heavy inhouse tests. Could you please take a look?

Attaching a binary of the simple repro.
ipf.bin.tar.gz

Expected behavior: successful exit
Actual behavior: failure with the below text (--debug-flags Exec)

1768896: system.cpu: T0 : 0x80040000    : jal zero, 4036             : IntAlu :  D=0x0000000080040004
build/RISCV/cpu/o3/[commit.cc](http://commit.cc/):748: warn: cpu may be stucked
build/RISCV/cpu/o3/[commit.cc](http://commit.cc/):745: warn: [sn:2804] c_lw a2, 52(s0)
build/RISCV/cpu/o3/[commit.cc](http://commit.cc/):746: panic: cpu stucked!!

To reproduce, run a simulation with command line:
../gem5.opt --debug-flags Exec ../configs/example/xiangshan.py --maxinsts 10000000000 --raw-cpt --generic-rv-cpt ./ipf.bin
gem5 version I'm using: a75b15c
nexus-am version: 5ca795e3c07658d7d98dd09adfbdbd2cbc342566

I am happy to provide any additional details by your request.
Thank you!

[tastynoob]

It more looks like there's a problem with your program "ipf.bin", It try to acces an illegal address "0x2000d0cf + 52".

[tastynoob]

It appears that the first instruction in your trap handler triggers an exception, then re-enters the trap handler, creating a loop that causes the system to stuck.

[jensen-yan]

It works fine with nemu or qemu, right? And difftest doesn't seem to be reporting an error either?

[ZyablitskiyA]

Issue title is a bit misleading. Sorry!
The real problem is not the hang in exception handler (this is expected), but raising instruction page fault exception itself.

With riscv64-nemu-interpreter-so we see
[NEMU]: force raise IPF
when jumping to the code located at the last 64byte line of the existing page (the test uses mmu).
At the same time, the next page is not mapped, and Gem5 multiline fetch fails on it.

There is no such issue in RTL code.

[jensen-yan]

Could you attach more error information? For example, the log for --debug-flags=Fetch , indicates that the MMU failed to allocate the page, right?