[llvm] r310075 - Port libFuzzer tests to LIT. Do not require two-stage build for check-fuzzer.

Justin Bogner via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 18 14:36:35 PDT 2017


George Karpenkov <ekarpenkov at apple.com> writes:
>> 
>> Yes, that's awkward on its own, but sometimes you're doing that
>> *anyway*. In particular, when I'm building an LLVM fuzzer tool (like the
>> forthcoming llvm-isel-fuzzer) on a branch of LLVM I'm obviously building
>> with coverage. I'd like to be able to run the fuzzer tests to verify
>> that the libFuzzer I'm linking that against works.
>> 
>>> After offline conversation:
>>> - seems that libFuzzer is correctly built without coverage, and
>>>   slowdown was probably caused by something else.
>>> - the aforementioned problems should disappear once libFuzzer is
>>>   moved to compiler-rt and becomes a part of clang's toolchain.
>> 
>> Yes, once libFuzzer is distributed with the compiler these issues go
>> away - at that point the libFuzzer and the clang that you're using are
>> tested together.
>> 
>> If that's happening in the next couple of weeks I'm comfortable with
>> waiting for it, but if it's likely to be months I think we need a way to
>> say "test with the host compiler". A CMake variable would work, but I
>> actually think doing that by default if LLVM_USE_SANITIZE_COVERAGE is
>> true would be even better.
>
> I think https://reviews.llvm.org/D36883 should solve your problems.

I think you forgot to add llvm-commits to that review - I don't see an
email for it on the list.

> Additionally, I think relying on LLVM_USE_SANITIZE_COVERAGE is not a
> good idea: libFuzzer is a tool in itself, and using it to fuzz LLVM is
> just one of possible applications, which definitely should not change
> how the library is compiled (e.g. it would be better to simply always
> append a flag which specifies that libFuzzer is compiled with no
> coverage, regardless of what LLVM_USE_SANITIZE_COVERAGE is set to).

This doesn't change how libFuzzer is compiled - it changes how its tests
are.

My thought process here is that, since LLVM_USE_SANITIZER_COVERAGE is
how we gate whether or not we're building tools that link libFuzzer (and
we're building those tools with sanitizer runtimes from the host
compiler), it also makes sense to gate what configuration of libFuzzer
we're testing.


More information about the llvm-commits mailing list