Yea, I know what the author intended :). However, no one other than the author ever used it that way, afaik.
On Tue, Sep 1, 2015 at 8:41 PM nathan binkert <[email protected]> wrote: > 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
