[PATCH] Tests and interface for LeakSanitizer.

[Kostya Serebryany]

================
Comment at: lib/lsan/tests/lsan_test.cc:165
@@ +164,3 @@
+  // To prevent the compiler from optimizing out this function.
+  (void) __sync_fetch_and_xor(&locals[0], p);
+  // Hide the result, just to suppress the compiler warning.
----------------
Sergey Matveev wrote:
> Alexander Potapenko wrote:
> > Isn't volatile enough to prevent the optimization?
> Not in my experience.
Please use
 break_optimization from sanitizer_common/tests/sanitizer_test_utils.h

================
Comment at: lib/lsan/lsan_testing_interface.h:1
@@ +1,2 @@
+//=-- lsan_testing_interface.h --------------------------------------------===//
+//
----------------
I am confused. I thought you are going to have this in lsan.h
Is this file only for testing lsan itself, or also for actually using lsan? 

================
Comment at: lib/lsan/tests/lsan_test.cc:32
@@ +31,3 @@
+uptr kMagic = 0xBABABABABABABABA;
+#define HIDE(p) ((void *)((uptr)(p) ^ kMagic))
+#define PEEK(p) HIDE(p)
----------------
any reason to use macros instead of inline functions? 

================
Comment at: lib/lsan/tests/lsan_test.cc:1
@@ +1,2 @@
+//=-- lsan_test.cc --------------------------------------------------------===//
+//
----------------
I like gtest very much, but I am not sure if it is well suited for testing lsan. 
lsan has a global state (allocator) which changes from one test to another. 
And we are actually testing how this global state is handled. 
So, I am inclined to use lit-style tests for lsan (maybe with a common header),
 leaving gtest tests for only a small ubset of lsan testing

What others think here? 

================
Comment at: lib/lsan/tests/lsan_test.cc:88
@@ +87,3 @@
+
+#ifdef __x86_64__
+volatile THREADLOCAL void *tl_var;
----------------
nested x86_64 ifdef? 


http://llvm-reviews.chandlerc.com/D677

BRANCH
  lsan_interface_and_tests

ARCANIST PROJECT
  compiler-rt