Compile with DummyClangFuzzer.cpp as entry point rather than
libFuzzer's main when coverage instrumentation is missing.
Details
Diff Detail
- Build Status
Buildable 10950 Build 10950: arc lint + arc unit
Event Timeline
It's not about coverage instrumentation (not) being present, but about libFuzzer's main() being present, right?
Will we be able to reuse some of Justin's code instead of creating one more main() function?
Or, why not link with libFuzzer (-fsanitize=fuzzer at link time) even if we don't us einstrumentation at compile time?
Yes.
Will we be able to reuse some of Justin's code instead of creating one more main() function?
This reuses the code that Justin moved to FuzzMutate/FuzzerCLI. That's why the main is so short. But perhaps we could move the main itself into FuzzerCLI?
Or, why not link with libFuzzer (-fsanitize=fuzzer at link time) even if we don't us einstrumentation at compile time?
When I tried this, I got undefined references to all kinds of __sanitizer_cov_* symbols.
Will we be able to reuse some of Justin's code instead of creating one more main() function?
This reuses the code that Justin moved to FuzzMutate/FuzzerCLI. That's why the main is so short. But perhaps we could move the main itself into FuzzerCLI?
Yes, having one common main makes sense, but see below.
Or, why not link with libFuzzer (-fsanitize=fuzzer at link time) even if we don't us einstrumentation at compile time?
When I tried this, I got undefined references to all kinds of __sanitizer_cov_* symbols.
I'd like to know more.
At least simple cases work fine:
clang++ ~/llvm/projects/compiler-rt/test/fuzzer/SimpleTest.cpp -std=c++11 -c && clang++ SimpleTest.o -fsanitize=fuzzer
You're right. I was trying to add -fsanitize=fuzzer to CMAKE_CXX_FLAGS right before the link command, which was causing a later compilation to give the error. Setting CMAKE_EXE_LINKER_FLAGS seems to work though.
This seems simpler and cleaner than the approach @bogner took.
We often suggest to code owners to implement their own dummy main to run fuzz targets as regression tests.
But for ourselves (LLVM) this recommendations makes less sense since libFuzzer is part of LLVM and we can use it's main directly.
grrr. I am sorry, I've just contradicted myself. :(
The goal here is to build the fuzz targets always and use them as tests, which includes building with any toolchain, including toolchains that don't support -fsanitize=fuzzer....
your original change actually solved this.
If you can *easily* share main() with the one in LLVM -- do it, otherwise don't bother.
Does the fuzzer main come from LLVM or compiler-rt now? There's still FuzzerMain.cpp in LLVM, but I'm not sure if we should be using that or not.
Don't reuse FuzzerMain.cpp.
There is llvm/tools/llvm-isel-fuzzer/DummyISelFuzzer.cpp which your main() duplicates, but these are in different projects (llvm vs clang) so perhaps it's ok.