similar to: moving libfuzzer to compiler-rt?

> I really like the property of libFuzzer living in its own place so that > it's easy to use without building the world But it’s not: the implementation of the coverage instrumentation is done in one of the sanitizers, so it’s impossible to just use libFuzzer without them. Furthermore, I would think that almost all libFuzzer users would use a sanitizer while fuzzing. I can see a few

On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > On Jul 12, 2017, at 11:01 AM, Kostya Serebryany <kcc at google.com> wrote: > One question: will it make sense to *copy* the code to the new location, > work on it, then delete the code from the old location, > instead of doing a move in a single commit? > I don't expect any

On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I already forgot why we decided not to move the code to compiler-rt. > > This would solve at least this problem. > Since we now have -fsanitize=fuzzer it will actually be pretty natural. > > > Licensing concerns, compiler-rt has a different license. > > BTW

On Tue, Jul 11, 2017 at 7:02 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > I’ve submitted a WIP PR: https://reviews.llvm.org/D35288 > Thanks for working in this! One question: will it make sense to *copy* the code to the new location, work on it, then delete the code from the old location, instead of doing a move in a single commit? I don't expect any dramatic changes

On Wed, Jul 12, 2017 at 11:54 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > On Jul 12, 2017, at 11:34 AM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov <ekarpenkov at apple.com> > wrote: > >> >> On Jul 12, 2017, at 11:01 AM, Kostya Serebryany <kcc at google.com> wrote:

> On Jul 17, 2017, at 2:06 PM, Daniel Berlin <dannyb at google.com> wrote: > > This process works legally, but i can't speak to whether the foundation would be okay with it, as it may result in bad press, etc, if you rip code out. Thank you for your reply! I have two additional questions: 1) Why is it ripping the code out if compiler-rt is still part of LLVM? 2) Does it mean

+ Chandler, Danny, We are considering to move the libFuzzer code from llvm to compiler-rt, and that implies a license change. Will it be sufficient to do the following? * e-mail to all contributors (a short list, below) asking for their consent * remove any code for which we did not get consent in, say, 1 week. (BTW, this list is actually much shorter, I recognize many of these as belonging

On Tue, May 9, 2017 at 1:56 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > Again, after offline conversation with Chris Bieneman: > > - move to compiler-rt would be too complicated due to change in licenses > - it would make much more sense to move to “tools” folder instead, for > the following reasons: > * conceptually, it’s a tool, not a library > *

> On May 10, 2017, at 4:43 PM, George Karpenkov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Actually, there’s another problem we have missed: libraries under `build/lib` are not installed into toolchain > on mac os (and neither on linux, I would suppose). Actually that isn't accurate. By default we don't install the LLVM libraries, but that is completely

On 9 May 2017 at 18:55, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, May 9, 2017 at 10:23 AM, Dan Liew <dan at su-root.co.uk> wrote: >> >> > Does anyone see good reasons why libFuzzer should remain in llvm repo >> > (as >> > opposed to moving it to compiler-rt)? >> >> Does moving LibFuzzer to compiler-rt imply that it

On Tue, May 2, 2017 at 4:28 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, May 2, 2017 at 12:26 PM, George Karpenkov <ekarpenkov at apple.com> > wrote: > >> From my understanding, all these problems can be solved entirely >> > by moving libfuzzer to compiler-rt, where (other) sanitizers already >> reside. >> >

> On May 9, 2017, at 3:00 PM, Kostya Serebryany <kcc at google.com> wrote: > > Thanks for the explanations! (it was worth asking) > > I do want to build libFuzzer itself (and its tests) using the just-built clang. So, llvm/runtimes then. > I'd name the directory llvm/runtimes/libFuzzer, if possible (the old path was lib/Fuzzer which is how the tool got it's

> On May 9, 2017, at 2:19 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > > +Chris. > > My understanding was that it is technically impossible for things in “lib”, as they are built first, and there’s no way to tell them to do that before “clang”. > I’m not a CMake expert, and I might be wrong. It is not impossible, it would just involve excessive hacks. Since it

On Tue, May 2, 2017 at 9:34 PM, Justin Bogner <mail at justinbogner.com> wrote: > Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> writes: > > On Tue, May 2, 2017 at 4:28 PM, Kostya Serebryany via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > >> On Tue, May 2, 2017 at 12:26 PM, George Karpenkov <ekarpenkov at apple.com > >

Hi All, Recently we have introduced a short syntactic sugar flag for compiling a file with libfuzzer: one just needs to add “-fsanitize=fuzzer” to the command line, and the driver would specify coverage flags and link with libfuzzer automatically. I wanted to ask whether it would make more sense to rename the flag to “-ffuzzer”, as it’s not a sanitizer, and it has a much heavier effect. Thanks,

I think libfuzzer deserves its own flag. I view fuzzing as a smarter testing technology while sanitizers are associated with inserting additional checks into the program. The different linking behavior is another major difference. Anna. > On Apr 27, 2017, at 4:08 PM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > on the one hand, -fsanitize=fuzzer might

> Does anyone see good reasons why libFuzzer should remain in llvm repo (as > opposed to moving it to compiler-rt)? Does moving LibFuzzer to compiler-rt imply that it is compiled as part of compiler-rt and shipped with it? How does that fit with LibFuzzer's model of allowing the user to provide their own `main()`. Would you just build two different libraries. One with a `main()` and

What makes the reports not actionable on windows? On Tue., 22 Aug. 2017, 3:49 pm Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think we should delete it. David implemented it a long time ago when he > was working on llvm-pdbdump, but he's moved on. Zach was never able to use > it effectively because he works on Windows, so the reports were not >

George Karpenkov <ekarpenkov at apple.com> writes: > Should -DCMAKE_CXX_COMPILER be also specified? CMake is smart enough to infer that from C_COMPILER: % grep CMAKE_CXX_COMPILER CMakeCache.txt CMAKE_CXX_COMPILER:FILEPATH=/Users/bogner/llvm-lkgc/bin/clang++ >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <mail at justinbogner.com> wrote: >> >> (kcc, george:

(kcc, george: sorry for the re-send, the first was from a non-list email address) My configuration for building the fuzzers in the LLVM tree doesn't seem to work any more (possibly as of moving libFuzzer to compiler-rt, but there have been a few other changes in the last week or so that may be related). I'm building with a fresh top-of-tree clang and setting -DLLVM_USE_SANITIZER=Address