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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
