From bf0340373c5d9e205956f3d8a5a40ab8fecf9984 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Mon, 18 Oct 2004 18:07:49 +0000 Subject: [PATCH] Arch-abstraction: fix up valgrind.h for future inclusion of other architectures. Had to recast it as valgrind.h.in; now at configure time the appropriate #define is set so that the appropriate snippet of assembly code is chosen. It's done this way rather than with x86/ etc. directories like the rest of Valgrind, because this header file must stand alone for inclusion by other programs. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2794 --- configure.in | 1 + include/Makefile.am | 9 +++++---- include/{valgrind.h => valgrind.h.in} | 23 ++++++++++++++++++++--- 3 files changed, 26 insertions(+), 7 deletions(-) rename include/{valgrind.h => valgrind.h.in} (94%) diff --git a/configure.in b/configure.in index dc0d7b0de..7ce44c545 100644 --- a/configure.in +++ b/configure.in @@ -396,6 +396,7 @@ AC_OUTPUT( tests/Makefile tests/vg_regtest tests/unused/Makefile + include/valgrind.h include/Makefile include/x86/Makefile auxprogs/Makefile diff --git a/include/Makefile.am b/include/Makefile.am index 6680b586a..ad8370e54 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -2,8 +2,9 @@ SUBDIRS = $(VG_ARCH) . EXTRA_DIST = \ - vg_profile.c \ - tool.h.base + tool.h.base \ + valgrind.h.in \ + vg_profile.c incincdir = $(includedir)/valgrind @@ -14,8 +15,8 @@ incinc_HEADERS = \ vg_kerneliface.h \ vg_skin.h -BUILT_SOURCES = tool.h -CLEANFILES = tool.h +BUILT_SOURCES = tool.h valgrind.h +CLEANFILES = tool.h valgrind.h tool.h: $(srcdir)/tool.h.base \ $(top_srcdir)/coregrind/gen_toolint.pl $(top_srcdir)/coregrind/toolfuncs.def diff --git a/include/valgrind.h b/include/valgrind.h.in similarity index 94% rename from include/valgrind.h rename to include/valgrind.h.in index 6422f886b..d7f57d76b 100644 --- a/include/valgrind.h +++ b/include/valgrind.h.in @@ -61,6 +61,7 @@ #include +#define __@VG_ARCH@__ // Architecture we're installed on /* This file is for inclusion into client (your!) code. @@ -70,15 +71,27 @@ The resulting executables will still run without Valgrind, just a little bit more slowly than they otherwise would, but otherwise unchanged. When not running on valgrind, each client request - consumes about 9 x86 instructions, so the resulting performance + consumes very few (eg. < 10) instructions, so the resulting performance loss is negligible unless you plan to execute client requests millions of times per second. Nevertheless, if that is still a problem, you can compile with the NVALGRIND symbol defined (gcc -DNVALGRIND) so that client requests are not even compiled in. */ - - #ifndef NVALGRIND + +/* The following defines the magic code sequence which the JITter spots and + handles magically. Don't look too closely at this; it will rot + your brain. We must ensure that the default value gets put in the return + slot, so that everything works when this is executed not under Valgrind. + Args are passed in a memory block, and so there's no intrinsic limit to + the number that could be passed, but it's currently four. + + Nb: we put the assembly code sequences for all architectures in this one + file. This is because this file must be stand-alone, so we can't rely on + eg. x86/ subdirectories like we do within the rest of Valgrind. +*/ + +#ifdef __x86__ /* This defines the magic code sequence which the JITter spots and handles magically. Don't look too closely at this; it will rot your brain. Valgrind dumps the result value in %EDX, so we first @@ -114,6 +127,10 @@ : "eax", "edx", "cc", "memory" \ ); \ } +#endif // __x86__ + +// Insert assembly code for other architectures here... + #else /* NVALGRIND */ /* Define NVALGRIND to completely remove the Valgrind magic sequence from the compiled code (analogous to NDEBUG's effects on