> On Aug. 28, 2015, 2:50 p.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? > > Steve Reinhardt wrote: > 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.
I like the idea of getting rid of the unprotected calls to Debug::breakpoint, I really can't see any other sensible use of it. I'm not sure if getting rid of the kill() call is necessary if you remove the unguarded calls. If you do get rid of it, consider adding a inform_once (if there is such a thing) to tell the user that the function was triggered. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3074/#review7068 ----------------------------------------------------------- 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
