Sounds good to me. What should happen with a SIGSEGV? I'm thinking #2. Ali
On Mar 7, 2009, at 3:15 PM, Steve Reinhardt wrote: > OK, this is coming along nicely but there are some policy questions I > could use some input on. What I've done is lumped the "run the test" > and "diff the outputs" steps into a single task from scons's > perspective, implemented as a python function, so now we have a lot > more control over what happens based on m5's exit status when running > the test. This is a good thing, as previously scons would consider an > abnormal m5 termination (e.g., an abort due to an assertion failure) > during a regression as a fatal error, meaning that I often ran > regressions with -k so I could catch all the failures. What I plan to > do now is that if m5 terminates with SIGABORT I will not bother to > diff the outputs and flag the test as failed, yet report to scons that > the task of running the test was completed successfully so that it > continues on to run other regressions, with no -k required. > > Of course with great power comes great responsibility, so now we have > to figure out what to do based on the m5 exit status. I think there > are four possible things we could do once an m5 test completes: > > 1. Diff the outputs and set the pass/fail status based on the result. > 2. Declare the test's status as failed regardless of the outputs but > consider the job of running the test as completed successfully. The > test will not be re-run unless some dependence changes (like one that > causes the m5 binary to get rebuilt). > 3. Consider the job of running the test as unsuccessful and don't > generate a pass/fail status. This will cause scons to terminate > unless you've used -k, and the test to be re-run if your re-run scons. > 4. Terminate scons unconditionally by calling scons's Exit() function. > > Here's my current plan: > > 1. Only when m5's exit status is 0. > 2. When m5 has a "normal" (non-signal) but non-zero exit, or is > terminated by a signal other than the ones listed in #3. > 3. When m5 is terminated by SIGTERM, SIGINT, SIGKILL, SIGHUP, or > SIGQUIT. > 4. Never. > > Questions: > - Do I have the right list of signals in #3 to distinguish premature > termination from m5 program errors? > - Is there any reason for SIGTERM et al (or some subset of them) to > cause #4 instead of #3? > > Thanks, > > Steve > _______________________________________________ > 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
