----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3074/#review7068 -----------------------------------------------------------
I think this makes sense, but I think this might breaks some of the assumptions of the Debug::breakpoint() call. This call seems to be sprinkled across NSGigE and Sinic devices. It seems like the author of those devices assumed that Debug::breakpoint() would be a no-op if a debugger isn't connected. Do we need to get rid of those calls before this change goes in? Or is the assumption that those devices are broken and no longer in use? - Andreas Sandberg On Aug. 24, 2015, 7:55 a.m., Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3074/ > ----------------------------------------------------------- > > (Updated Aug. 24, 2015, 7:55 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11062:fbce13fdad11 > --------------------------- > sim: don't ignore SIG_TRAP > > By ignoring SIG_TRAP, using --debug-break <N> when not connected to > a debugger becomes a no-op. Apparently this was intended to be a > feature, though the rationale is not clear. > > If we don't ignore SIG_TRAP, then using --debug-break <N> when not > connected to a debugger causes the simulation process to terminate > at tick N. This is occasionally useful, e.g., if you just want to > collect a trace for a specific window of execution then you can combine > this with --debug-start to do exactly that. > > > Diffs > ----- > > src/sim/init_signals.cc 842f56345a421244a7a8988a5bc4fb1cfbf409ef > > Diff: http://reviews.gem5.org/r/3074/diff/ > > > Testing > ------- > > > Thanks, > > Steve Reinhardt > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
