|
From: <sv...@va...> - 2005-07-29 08:51:39
|
Author: sewardj
Date: 2005-07-29 09:51:34 +0100 (Fri, 29 Jul 2005)
New Revision: 4292
Log:
Handle a failure case more gracefully.
Modified:
trunk/coregrind/m_scheduler/scheduler.c
Modified: trunk/coregrind/m_scheduler/scheduler.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_scheduler/scheduler.c 2005-07-28 16:26:34 UTC (rev =
4291)
+++ trunk/coregrind/m_scheduler/scheduler.c 2005-07-29 08:51:34 UTC (rev =
4292)
@@ -760,6 +760,18 @@
VG_(printf)("dump translations done.\n");
break;
=20
+ 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:=20
vg_assert2(0, "VG_(scheduler), phase 3: "
"unexpected thread return code (%u)", trc);
|