Hi Nilay, Personally I think that if it's not possible to debug the problem from the error message, then the error message should be improved. If you're in a situation where the error message isn't good enough and you need to figure out why, you can put a breakpoint on the call to fatal before you start running (and presumably you know which call to fatal you care about, because you're rerunning under the debugger after your first run died).
Also abort will typically do a core dump (if you're not under the debugger, and haven't otherwise disabled core dumps), which is pretty annoying when it's a user error and not a gem5 bug. With fatal calling abort now, it's really no different from panic, which says that we really shouldn't have two different calls---which I don't agree with either, but it's the logical conclusion of this patch, IMO. Steve On Thu, Feb 6, 2014 at 2:28 PM, Nilay Vaish <[email protected]> wrote: > changeset f60cd60445b7 in /z/repo/gem5 > details: http://repo.gem5.org/gem5?cmd=changeset;node=f60cd60445b7 > description: > base: calls abort() from fatal > Currently fatal() ends the simulation in a normal fashion. This > results in > the call stack getting lost when using a debugger and it is not > always > possible to debug the simulation just from the information > provided by the > printed error message. Even though the error is likely due to a > user's fault, > the information available should not be thrown away. Hence, this > patch to > call abort() from fatal(). > > diffstat: > > src/base/misc.hh | 5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diffs (17 lines): > > diff -r b29a58680b47 -r f60cd60445b7 src/base/misc.hh > --- a/src/base/misc.hh Thu Feb 06 16:30:12 2014 -0600 > +++ b/src/base/misc.hh Thu Feb 06 16:30:13 2014 -0600 > @@ -77,11 +77,10 @@ > // This implements a cprintf based fatal() function. fatal() should > // be called when the simulation cannot continue due to some condition > // that is the user's fault (bad configuration, invalid arguments, > -// etc.) and not a simulator bug. fatal() calls exit(1), i.e., a > -// "normal" exit with an error code, as opposed to abort() like > +// etc.) and not a simulator bug. fatal() calls abort() like > // panic() does. > // > -#define fatal(...) exit_message("fatal", 1, __VA_ARGS__) > +#define fatal(...) exit_message("fatal", -1, __VA_ARGS__) > > void > __base_message(std::ostream &stream, const char *prefix, bool verbose, > _______________________________________________ > 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
