similar to: custom-crossover libFuzzer test

> 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

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,

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 > *

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

> 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

> 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

+ 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 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 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 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 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 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

Timeouts when running tests are annoying, but for many libFuzzer tests lacking -runs argument that’s an expected failure mode. Should we go through all the tests making sure that -runs is supplied? Motivation: https://bugs.llvm.org/show_bug.cgi?id=38034

Hi All, Currently libfuzzer depends on (often freshly built) clang, yet the dependency is not explicitly specified in cmake. That leads to various issues: for instance, it’s not possible to check out LLVM repo and run libfuzzer tests: one would often need to compile fresh clang first, and then create a separate build directory, where libfuzzer could be tested. For the buildbot this problem is

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 > >

This sounds reasonable to me. Some tests could probably use a seed as well. On Thu, Jul 5, 2018 at 3:55 PM George Karpenkov <ekarpenkov at apple.com> wrote: > Timeouts when running tests are annoying, > but for many libFuzzer tests lacking -runs argument that’s an expected > failure mode. > Should we go through all the tests making sure that -runs is supplied? > >

Hi All, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have looked into tools/llvm-pdbutil, and “ninja llvm-pdbutil-fuzzer” does not build at all, and the error refers to non-existent headers. The last update to the codebase is reasonably recent, and was done in June 2017. Is anyone using it?

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

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:

Hi, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have tried to compile llvm-mc-assemble-fuzzer, and llvm-mc-disassemble-fuzzer, and I couldn’t build either of those. For the first one, the reason is that it refers to a nonexistent enum, and for the second one I believe the reason is that it