- User Since
- Oct 3 2012, 4:55 AM (254 w, 2 d)
Mon, Aug 14
Fri, Aug 11
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.
Thu, Aug 10
LGTM with a nit
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?
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
Wed, Aug 9
LGTM with nits, thanks!
Tue, Aug 8
LGTM with a couple if nits in the README
To save one hop, who do you want this to be split in patches?
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
Mon, Aug 7
Why do we need LLVM_ENABLE_RTTI=ON here?
Fri, Aug 4
Thu, Aug 3
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.
Wed, Aug 2
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)
You don't have commit access, do you?
I'll land it later today, unless someone else beats me to it.
Tue, Aug 1
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.
Mon, Jul 31
Take a look at test/asan/TestCases/sleep_before_dying.c,
you will need a similar one.
Fri, Jul 28
Thu, Jul 27
What about tests?
(Well, this probably applies to all fuchsia-related patches).
Wed, Jul 26
Tue, Jul 25
check-msan is only available on platforms that support msan (i.e. Linux).
I *think* the same it true about xray