> On Aug. 28, 2015, 6:50 a.m., Andreas Sandberg wrote: > > 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?
Good catch... I hadn't noticed that. There are a few calls outside of those two devices as well: there's a debugbreak pseudo-inst, a BreakPCEvent, and some pretty idiosyncratic usage in base/statistics.cc and arch/alpha/ev5.cc. My inclination is to get rid of all the unprotected calls, but leave the ones that require some intention on the part of the user (the pseudo-inst and the BreakPCEvent). I'd also consider getting rid of the kill() call in Debug::breakpoint and requiring the user to manually set a breakpoint there from gdb (you could even put it in your .gdbinit) if we're concerned about things like the pseudo-inst inadvertently killing the process, but I'd like to know whether that's actually an issue before we make that change. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3074/#review7068 ----------------------------------------------------------- On Aug. 23, 2015, 11:55 p.m., Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3074/ > ----------------------------------------------------------- > > (Updated Aug. 23, 2015, 11:55 p.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
