Add a comment explaining the recently changed behaviour of
RUNNING_ON_VALGRIND.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3651 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/coregrind/vg_scheduler.c b/coregrind/vg_scheduler.c
index 585086d..4a4eacc 100644
--- a/coregrind/vg_scheduler.c
+++ b/coregrind/vg_scheduler.c
@@ -989,6 +989,8 @@
break;
}
+ // Nb: this looks like a circular definition, because it kind of is.
+ // See comment in valgrind.h to understand what's going on.
case VG_USERREQ__RUNNING_ON_VALGRIND:
SET_CLREQ_RETVAL(tid, RUNNING_ON_VALGRIND+1);
break;
diff --git a/include/valgrind.h.in b/include/valgrind.h.in
index c534985..8df4f62 100644
--- a/include/valgrind.h.in
+++ b/include/valgrind.h.in
@@ -244,8 +244,9 @@
#define __extension__
#endif
-/* Returns 1 if running on Valgrind, 0 if running on the real CPU.
- Currently implemented but untested. */
+/* Returns the number of Valgrinds this code is running under. That is,
+ 0 if running natively, 1 if running under Valgrind, 2 if running under
+ Valgrind which is running under another Valgrind, etc. */
#define RUNNING_ON_VALGRIND __extension__ \
({unsigned int _qzz_res; \
VALGRIND_MAGIC_SEQUENCE(_qzz_res, 0 /* returned if not */, \