The author of breakpoint did intend it to be a noop that would cause a trap in gdb. :) Setting a breakpoint from gdb isn't always easy. Sometimes you need to have very specific conditions to make things happen that are hard to code in gdb.
That said, it's not necessary to ignore sigtrap since you can just ask GDB to ignore the signal and not deliver it to the process. Nate On Tue, Sep 1, 2015 at 9:09 AM, Steve Reinhardt <[email protected]> wrote: > > > > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
