Hi Ciro, As far as I know, it's not desired behavior for the exit status to be 0 when a panic happens. It's probably just something that has never come up.
Feel free to submit a patch to change this! It looks like something would need to change in `raiseFatalSignal()` in src/sim/init_signals.cc. Cheers, Jason On Sun, Aug 12, 2018 at 10:55 AM Ciro Santilli <ciro.santi...@gmail.com> wrote: > 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
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
