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

diff --git a/configure.in b/configure.in
index dc0d7b0de81a13e7806a02ab5b29114cb4c1bacc..7ce44c5458c6ded3f18716389bf3ca979b1d1eae 100644 (file)
--- 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 6680b586a28f0ed7ba5db299ec4bfa086b27e42a..ad8370e547c4f4766c2b0d60ddd194c8f1641a7b 100644 (file)
--- 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 6422f886b5854da5de4665029dd4cc8b9650fb32..d7f57d76b07c5e3e32d6a8c5b8e8b2b9308be36a 100644 (file)
--- a/include/valgrind.h
+++ b/include/valgrind.h.in
@@ -61,6 +61,7 @@
 
 #include <stdarg.h>
 
+#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.
+*/
 
-#ifndef NVALGRIND
+#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