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

Reply via email to