> 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.
This all sounds great. I've got some test framework stuff in the works that should make adding tests and picking subsets of tests to run a lot easier. >Questions: > - Do I have the right list of signals in #3 to distinguish premature > termination from m5 program errors? I think so. > - Is there any reason for SIGTERM et al (or some subset of them) to > cause #4 instead of #3? Hard to say. I never use -k with tests (only when trying to get through compiler stuff), but I generally hate when programs don't terminate on SIGINT (Ctrl-C). Of course, I could just not ask for any tests to run when using -k and it wouldn't be a problem. Then again, a quick succession of SIGINTs will probably still terminate the program since SCons itself might catch one of them. Then again, if SCons forks a subprocess, but you send a CTRL-C to the terminal, who gets it? I honestly don't remember. In the shell, it would go to whatever process is currently running, but I think that in that case, the shell might actually be forwarding the signal. So, would python (scons) get it, or m5? Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
