A note that Valgrind does not give a good stacktrace when the problem

is involving an assembly function.
Testcase was BUG#1194
SELECT @A:=1; SELECT @A, @A:=1;

BUILD/compile-pentium-valgrind-max

 #! /bin/sh
 
+echo "\
+********************************************************************************
+Note that by default BUILD/compile-pentium-valgrind-max calls 'configure' with
+--enable-assembler. When Valgrind detects an error involving an assembly
+function (for example an uninitialized value used as an argument of an assembly
+function), Valgrind will not print the stacktrace and 'valgrind
+--gdb-attach=yes' will not work either. If you need a stacktrace in those cases,
+you have to run BUILD/compile-pentium-valgrind-max with the --disable-assembler
+argument.
+********************************************************************************
+"
+
 path=`dirname $0`
 . "$path/SETUP.sh"
 
@@ -11,3 +23,15 @@ extra_configs="$pentium_configs $debug_configs"
 extra_configs="$extra_configs --with-berkeley-db --with-innodb --with-embedded-server --with-openssl"
 
 . "$path/FINISH.sh"
+
+echo "\
+********************************************************************************
+Note that by default BUILD/compile-pentium-valgrind-max calls 'configure' with
+--enable-assembler. When Valgrind detects an error involving an assembly
+function (for example an uninitialized value used as an argument of an assembly
+function), Valgrind will not print the stacktrace and 'valgrind
+--gdb-attach=yes' will not work either. If you need a stacktrace in those cases,
+you have to run BUILD/compile-pentium-valgrind-max with the --disable-assembler
+argument.
+********************************************************************************
+"