I'd avoid such extra complexity, after all this is just an example.
One can force the full rebuild with --no-cache. It'll take just a bit more time since most of the time is consumed by the compiler builds.
BTW, my old svn (1.8.8, Ubuntu 14.04) does't have "info --show-item revision"

fix 'svn co' command (apparently it did not matter though)

LGTM from fuzzing POV, let's see how this works.

LGTM with a nit

yes

LGTM, thanks!
But please also change the docs.

Than -fsanitize=fuzzer-no-link :)
Will you have time to make this change?

Naming is hard. maybe -fsanitize=fuzzer-no-link?

In D32193#838574, @george.karpenkov wrote:

@kcc I guess I didn't have this problem yet as somehow on macos the symbol collision seems to be resolved "properly" in most cases.
Honestly the way I would do it is by providing a function run_fuzzer which would take a function pointer with an explicit callback.

OMG no.

I am using TotT clang to build libpng with fsanitize=fuzzer and libpng's configure script fails
configure: error: C compiler cannot create executables

There is a problem with -fsanitize=fuzzer

LGTM with nits, thanks!

LGTM

LGTM

In D36477#836027, @farahhariri wrote:

In D36477#835621, @kcc wrote:

are tests possible here?

my first thought on testing is that I could add a dummy code that
has a strcpy call for example, and define dfsan_weak_hook_strcpy
such that it sets some boolean to true (initially false). And then
assert that the value is changed to true.

LGTM with a couple if nits in the README

To save one hop, who do you want this to be split in patches?

Looks good!
Now, please add a clang/tools/clang-fuzzer/README.txt describing how to build the fuzzers (both the old one and the new one) and how to run them.
For the new one explain how to install the deps

I am fine with breaking the API. Whoever uses this API will need to add a tiny bit of code to work with the new compiler (and that code will be compatible with the old version).
It's better to break the API this way than to introduce the flags or weak aliases, etc

are tests possible here?

• I'd like to see some kind of design doc first (preferably, in a form of comment in e.g. FuzzerDFSan.h
• Is it possible to split this patch into several (e.g. can static-analyzer-pl-parser.py go separately? )
• does static-analyzer-pl-parser.py have to be in pythoin? Why is C++ less/not suitable?
• tests are must-have
• don't copy-paste code (e.g. lots of changes in FuzzerMutate.cpp seem similar)
• try to put dfsan-specific code in separate file(s)
• please obey the LLVM coding style

In D36324#835415, @morehouse wrote:

In D36324#834660, @kcc wrote:

Why do we need LLVM_ENABLE_RTTI=ON here?

Attempting to build without it yields all kinds of protobuf errors. For example:

Why do we need LLVM_ENABLE_RTTI=ON here?

+bogner@ FYI

LGTM

In D36324#832271, @thakis wrote:

Why should this be part of llvm? This seems to come with very heavy dependencies (protobuf), and LLVM has historically tried to minimize the number of things it depends on.

LGTM

LGTM

LGTM with a nit, and thanks again for doing this.
I guess you may want to submit this tomorrow morning, so that we don't spoil the tonight's LLVM social with whatever this is going to break.

Yep, this is ok now. Looking further.

Now, something is fishy here.
check-fuzzer indeed passes, but if I crippled the merge functionality (replace OUTER with OTTER in FuzzerMerge.cpp) it still passes, i.e. the tests don't work any more.

Once finalized and submitted, I'll take care of the linux buildbot.

Yes, please make check-fuzzer a no-op on windows

But that won't matter for us soon, right?

unlikely a good solution.
maybe just increase the # of runs to 10000000 ?

I would still suggest to make check-fuzzer a no-op on Windows so that we don't need to touch the windows bot configs now.

LGTM

In D36242#829800, @george.karpenkov wrote:

@kcc my bad, strnstr is actually not available outside of FreeBSD-like systems.
Would it be OK to change to strstr?

LGTM

In D36205#829472, @george.karpenkov wrote:

@kcc Does it mean you would be OK with the change moving the compilation commands to LIT, and only compiling unit-tests in CMake?

I prefer moving compilation commands to LIT.

We will have to do something of this sort anyway once we make 'check-fuzzer' a part of 'check-all' on Linux and Mac.

Is there an option to make check-fuzzer a no-op on windows?
This way we won't have to touch the bot (and then touch it again, when windows is reinstated)

LGTM
You don't have commit access, do you?
I'll land it later today, unless someone else beats me to it.

I don't mind, but please let Zack or Reid review this.
The question is: do we need to remove all traces of windows support from tests, or just disable check-fuzzer on the bot and remove only the parts that are blocking the refactoring.

AFAICT, libFuzzer on Windows has no active users or contributors.
If you ask me, I would prefer to

a) disable check-fuzzer on the windows bot
b) complete the migration from llvm to compiler-rt, while preserving the status quo only on Linux and Mac
c) let anyone who cares about windows (if anyone left) fix it once the dust settles.

Take a look at test/asan/TestCases/sleep_before_dying.c,
you will need a similar one.

LGTM

What about tests?
(Well, this probably applies to all fuchsia-related patches).

check-msan is only available on platforms that support msan (i.e. Linux).
I *think* the same it true about xray