I've always remembered it as the simulator panicking when something
unexpected happens, definitely not including user error, and fatal is
the other one. I almost always use panic because I don't deal with user
input and configuration that much, although putting in more of that is
part of what I'll be doing before pushing my x86 stuff. I don't like to
use fatal because it makes figuring things out in gdb harder. I don't
remember exactly why, but panic stops gdb immediately and fatal finishes
out the program and quits which makes it a lot harder to examine what
actually happened. I don't remember the specifics of any time that was a
problem since I think it was a while ago, but if there are more detailed
messages from fatal it might not be as big of an issue.
As far as the links to the wiki, I think some form of that would be a
good idea. The message should be descriptive, but if there was a page
with a somewhat detailed description of what m5 is complaining about,
why it might have happened, and some things to try to fix it (not it for
writing all that), that would probably help people a lot.
Gabe
Ali Saidi wrote:
On May 28, 2008, at 11:23 AM, nathan binkert wrote:
panic() -- An assert that isn't compiled out
fatal() -- some configuration parameter caused a problem
Ok, I thought so. Do we want to keep these names? I will promise
that I have learned finally, but the names seem a bit to synonymous to
me. I will go through my code and convert the proper things to fatal
since I am at fault for not doing this correctly. Does everyone else
seem to do this stuff correctly, or should we go through more of them?
I just learned them and they make sense to me.
I would also like to add an option to allow panic and fatal (or
whatever their replacements) to raise exceptions into the python so we
can get a stack trace. I don't know if this influences any thoughts
on this.
I spent some time trying to do this, if you remember.I never got it to
work correctly from inside of m5, but perhaps someone else would have
better luck.
Can't we make the error messages themselves descriptive, rather than
requiring a two step process?
Well, something like the stat check error needs more description, and
a link to the wiki page would be useful. We could do it only for the
error messages that are necessary of course, but it seems that some of
the error messages should have a lot more information.
Most of these errors panic in the c++ and call _exit(). I don't
think people
are seeing python error messages that often.
I think some of the configuration script things could be trapped in
python.
I don't know if it's worth spending time adding more indirection to
the error path so python can print an error. If the error is fatal
python isn't going to be able to correct it and continue.
Ali
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
