# Linux Kernel Module Cheat

###### 17.6.1.3.2. Exit gem5 on panic

gem5 9048ef0ffbf21bedb803b785fb68f83e95c04db8 (January 2019) can detect panics automatically if the option `system.panic_on_panic` is on.

It parses kernel symbols and detecting when the PC reaches the address of the `panic` function. gem5 then prints to stdout:

    Kernel panic in simulated kernel

and exits with status -6.

At gem5 ff52563a214c71fcd1e21e9f00ad839612032e3b (July 2018) behaviour was different, and just exited 0: https://www.mail-archive.com/gem5-users@gem5.org/msg15870.html TODO find fixing commit.

We enable the `system.panic_on_panic` option by default on `arm` and `aarch64`, which makes gem5 exit immediately in case of panic, which is awesome!

If we don’t set `system.panic_on_panic`, then gem5 just hangs on an infinite guest loop.

TODO: why doesn’t gem5 x86 ff52563a214c71fcd1e21e9f00ad839612032e3b support `system.panic_on_panic` as well? Trying to set `system.panic_on_panic` there fails with:

    tried to set or access non-existentobject parameter: panic_on_panic

However, at that commit panic on x86 makes gem5 crash with:

    panic: i8042 "System reset" command not implemented.

which is a good side effect of an unimplemented hardware feature, since the simulation actually stops.

The implementation of panic detection happens at: https://github.com/gem5/gem5/blob/1da285dfcc31b904afc27e440544d006aae25b38/src/arch/arm/linux/system.cc#L73

            kernelPanicEvent = addKernelFuncEventOrPanic<Linux::KernelPanicEvent>(
                "panic", "Kernel panic in simulated kernel", dmesg_output);

Here we see that the symbol `"panic"` for the `panic()` function is the one being tracked.

Related thread: https://stackoverflow.com/questions/56032347/is-there-a-way-to-identify-if-gem5-run-got-over-successfully