Fail the build if MSan is built with assembly.

MSan works by instrumenting memory accesses in the compiler. Accesses from
uninstrumented code, such as assembly, are invisible to it. MSan will
incorrectly report reads from assembly-initialized memory as uninitialized.

To avoid confusing downstream consumers with false positives, catch this at
compile-time with a more useful error.

Update-Note: BoringSSL with MSan and assembly doesn't work, but now rather than
crashing at runtime, it will fail to build altogether. It's possible someone
was building BoringSSL with MSan and either not running it at all or just not
exercising the codepaths that break.

Bug: 252
Change-Id: I0c8b0fa3c2d1e584b3f40d532a668a8c9be06cb7
Reviewed-on: https://boringssl-review.googlesource.com/29928
Reviewed-by: Adam Langley <agl@google.com>

crypto/internal.h

@@ -151,6 +151,19 @@ extern "C" {
 #endif
 
 
+#if defined(OPENSSL_MSAN) && !defined(OPENSSL_NO_ASM)
+// MSan works by instrumenting memory accesses in the compiler. Accesses from
+// uninstrumented code, such as assembly, are invisible to it. MSan will
+// incorrectly report reads from assembly-initialized memory as uninitialized.
+// If building BoringSSL with MSan, exclude assembly files from the build and
+// define OPENSSL_NO_ASM.
+//
+// This is checked here rather than in base.h because the consumer might not
+// define OPENSSL_NO_ASM. It is only necessary for BoringSSL source files to be
+// built with it.
+#error "BoringSSL must be built with assembly disabled to use MSan."
+#endif
+
 #if defined(OPENSSL_X86) || defined(OPENSSL_X86_64) || defined(OPENSSL_ARM) || \
     defined(OPENSSL_AARCH64) || defined(OPENSSL_PPC64LE)
 // OPENSSL_cpuid_setup initializes the platform-specific feature cache.