[PATCH] DFSan-based fuzzer (proof of concept).

[Kostya Serebryany]

> We might also want to reset the DFSan state after each iteration, but that can probably come later.


Yep. 
So far everything works w/o resetting the dfsan state because I taint the global input vector which never gets reallocated. 
I guess we may run out of dfsan labels in long fuzzing session woth resetting the DFSan state.


================
Comment at: lib/Fuzzer/FuzzerFlags.def:47
@@ -46,1 +46,3 @@
             "Number of simultaneous worker processes to run the jobs.")
+FUZZER_FLAG(int, dfsan, 1, "Use DFSan for taing-guided mutations. No-op unless "
+                           "the DFSan instrumentation was compiled in.")
----------------
pcc wrote:
> taint-guided
done

================
Comment at: lib/Fuzzer/dfsan_fuzzer_abi.list:12
@@ +11,2 @@
+# Don't add extra parameters to the Fuzzer callback.
+fun:TestOneInput=uninstrumented
----------------
pcc wrote:
> uninstrumented+discard maybe? Though this shouldn't matter if the function is only called from non-dfsan code.
Yes, this code is expected to be called *only* from non-instrumented code. 

================
Comment at: lib/Fuzzer/test/dfsan/CMakeLists.txt:5
@@ +4,3 @@
+
+set(CMAKE_CXX_FLAGS_RELEASE
+  "${LIBFUZZER_FLAGS_BASE} -O0 -fno-sanitize=all -fsanitize=dataflow -mllvm -sanitizer-coverage-experimental-trace-compares=1 -fsanitize-blacklist=${DFSAN_FUZZER_ABI_LIST}")
----------------
pcc wrote:
> Doesn't this mean that the test will only use DFSan in release builds? Probably better to set the COMPILE_FLAGS property on the target.
Err. I think I tried and it did not work. 
Let me try to wrestle with it separately if/when we need a Debug build.

http://reviews.llvm.org/D8669

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/