similar to: llvm-mc-[dis]assemble-fuzzer status?

On Tue, Aug 22, 2017 at 4:34 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, Aug 22, 2017 at 4:21 PM, George Karpenkov <ekarpenkov at apple.com> > wrote: > >> 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.

On Fri, Aug 25, 2017 at 8:51 AM, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > (removed my @imgtec.com address since it no longer exists) > > Sorry for the slow reply, it's a busy time for me right now. > > > On 23 Aug 2017, at 00:21, George Karpenkov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > As a

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:

On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Aug 24, 2017 at 3:20

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

On Thu, Aug 24, 2017 at 6:30 PM, Justin Bogner <mail at justinbogner.com> wrote: > Peter Collingbourne <peter at pcc.me.uk> writes: > > On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> > wrote: > > > >> > >> > >> On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > >> wrote:

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?

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

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 >

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

FWIW I think that one was always flaky. > On Jan 4, 2019, at 2:53 PM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +Matt Morehouse <mailto:mascasa at google.com> > > On Fri, Jan 4, 2019 at 11:43 AM David Greene via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Continuing my quixotic effort

+ 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 Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

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

Hi Mitch, Thank you for the response. 1. You don't need to build the library with `-fsanitize-coverage=...`, using `-fsanitize=fuzzer-no-link,address` should be sufficient. - Acknowledged 2. (although you can actually build object files/shared libraries with -fsanitize=fuzzer, and the libFuzzer main won't be linked, if this makes your build process easier). - with just the *fuzzer

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

(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

> 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