Handle a failure case more gracefully.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4292 a5019735-40e9-0310-863c-91ae7b9d1cf9

1 files changed, 12 insertions, 0 deletions

diff --git a/coregrind/m_scheduler/scheduler.c b/coregrind/m_scheduler/scheduler.c
index 41b41acc..ed4155b4 100644
--- a/coregrind/m_scheduler/scheduler.c
+++ b/coregrind/m_scheduler/scheduler.c
@@ -760,6 +760,18 @@ VgSchedReturnCode VG_(scheduler) ( ThreadId tid )
             VG_(printf)("dump translations done.\n");
          break;
 
+      case VG_TRC_INVARIANT_FAILED:
+         /* This typically happens if, after running generated code,
+            it is detected that host CPU settings (eg, FPU/Vector
+            control words) are not as they should be.  Vex's code
+            generation specifies the state such control words should
+            be in on entry to Vex-generated code, and they should be
+            unchanged on exit from it.  Failure of this assertion
+            usually means a bug in Vex's code generation. */
+         vg_assert2(0, "VG_(scheduler), phase 3: "
+                       "run_innerloop detected host "
+                       "state invariant failure", trc);
+
       default: 
 	 vg_assert2(0, "VG_(scheduler), phase 3: "
                        "unexpected thread return code (%u)", trc);