[PATCH] D83494: [libFuzzer] Link libFuzzer's own interceptors when other compiler runtimes are not linked.

[Matt Morehouse via Phabricator via cfe-commits]

morehouse added inline comments.


================
Comment at: compiler-rt/test/fuzzer/custom-allocator.test:2
+UNSUPPORTED: freebsd
+RUN: %cpp_compiler -fno-sanitize=all -fno-builtin %S/CustomAllocator.cpp -fPIC %ld_flags_rpath_so1 -O0 -shared -o %dynamiclib1
+RUN: %cpp_compiler -fno-sanitize=address %S/CustomAllocatorTest.cpp %ld_flags_rpath_exe1 -o %t-NoAsanCustomAllocatorTest
----------------
dokyungs wrote:
> morehouse wrote:
> > Why do we need each of these flags?
> With all the flags, I designed this test for the recent failure scenario in which tcmalloc calls strncmp (+memcmp/strstr) when the fuzzer interceptor library is linked into the libFuzzer executable.
> 
> As such, we need to turn off ASan (-fno-sanitize=address) when building the executable to let the fuzzer interceptor library be linked.
> 
> As to the flags used to build the allocator shared library, I wanted to disable ASan and Fuzzer (via `-fno-sanitize=all`) because allocator libraries are typically not instrumented for OOB/UAF errors or coverage. I also wanted to prevent the compiler from optimizing out our calls to strncmp(+memcmp/strstr) by giving `-fno-builtin`; calls to these functions must go to the fuzzer interceptor library to comply with the scenario.
Yes, those flags make sense.  What about `-fPIC %ld_flags_rpath_so1 -O0 -shared`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83494/new/

https://reviews.llvm.org/D83494