I've noticed that as of ff52563a214c71fcd1e21e9f00ad839612032e3b, when
there is a kernel panic, and I hack fs.py to set `system.panic_on_panic`
with:
diff --git a/configs/example/fs.py b/configs/example/fs.py
index 4031fd05e..0f502a34a 100644
--- a/configs/example/fs.py
+++ b/configs/example/fs.py
@@ -395,5 +395,6 @@ if buildEnv['TARGET_ISA'] == "arm" and
options.generate_dtb:
sys = getattr(root, sysname)
sys.dtb_filename = create_dtb_for_system(sys, '%s.dtb' %
sysname)
+test_sys.panic_on_panic = True
Simulation.setWorkCountOptions(test_sys, options)
Simulation.run(options, root, test_sys, FutureClass)
I get the stack trace at then end:
--- BEGIN LIBC BACKTRACE ---
but the exit status is 0 and not 1.
The code path calls panic(), which calls ::abort(), but then it seems that
the abort handler that prints the backtrace returns 0 instead of 1.
Is this desired behavior?
It matters because exit status of 1 makes it easier to git bisect run,
which is super important to have.
Now I'm parsing logs to determine if an error happened, which is nasty.
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
