gem5-dev@gem5.org

The gem5 Developer List

View all threads

Skipping store queue searches when issuing loads causes crashes

M
muke101
Tue, Oct 31, 2023 4:38 PM

Hi, I'm modifying Gem5 (version 22.0.0.1) for a research project and one thing I'm testing is using special loads which when issued do not search the store queue for a potential store forward.

I've implemented this with a goto in LSQUnit::read​ in lsq_unit.cc​ from right before the loop that searches the store queue (starting line 1390) to the end of the loop, where the cache access is implemented (line 1568).

For some reason this change has caused Gem5 to crash fairly often. I'm running Spec2017 using simpoints and around 40% of generated checkpoints crash with the following error:

build/ARM/sim/faults.cc:102: panic: panic condition !handled && !tc->getSystemPtr()->trapToGdb(SIGSEGV, tc->contextId()) occurred: Page table fault when accessing virtual address 0x54000000540​

This only happens with checkpoints containing my new load instruction opcode, and not checkpoints without them (which are also otherwise identical). Furthermore these broken checkpoints run fine again as soon as this goto statement is removed.

Does anyone have any ideas why this could be happening? I've tried reading through the store forwarding code and can't figure out why skipping it altogether could cause any problems.

Thanks.

Hi, I'm modifying Gem5 (version 22.0.0.1) for a research project and one thing I'm testing is using special loads which when issued do not search the store queue for a potential store forward. I've implemented this with a goto in LSQUnit::read​ in lsq_unit.cc​ from right before the loop that searches the store queue (starting line 1390) to the end of the loop, where the cache access is implemented (line 1568). For some reason this change has caused Gem5 to crash fairly often. I'm running Spec2017 using simpoints and around 40% of generated checkpoints crash with the following error: build/ARM/sim/faults.cc:102: panic: panic condition !handled && !tc->getSystemPtr()->trapToGdb(SIGSEGV, tc->contextId()) occurred: Page table fault when accessing virtual address 0x54000000540​ This only happens with checkpoints containing my new load instruction opcode, and not checkpoints without them (which are also otherwise identical). Furthermore these broken checkpoints run fine again as soon as this goto statement is removed. Does anyone have any ideas why this could be happening? I've tried reading through the store forwarding code and can't figure out why skipping it altogether could cause any problems. Thanks.