similar to: Using Libfuzzer on a library - linking the library to the fuzz target

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

Kostya, I took a quick stab at patching libFuzzer for Apple, but so far I'm thinking something else is incorrect. Patch is attached but when I went to reproduce the examples, the toy example went fine, but with PCRE and Heartbleed I noticed the coverage statistics were pretty poor, and didn't find anything. Admittedly I moved onto Heartbleed pretty quickly so PCRE probably isn't the

FWIW see also http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043301.html As far as I understand DFSan functionality isn't required for libFuzzer to work, so it should be safe to disable DFSan support on Mac. On Wed, Jul 8, 2015 at 7:45 AM, Kostya Serebryany <kcc at google.com> wrote: > +pcc , glider > > On Mon, Jul 6, 2015 at 12:59 PM, Juan Ceasar <juan.d.ceasar at

(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

libFuzzer is Clang's fuzzer, and alternative to using AFL: https://llvm.org/docs/LibFuzzer.html I implemented an alternative method of fuzzing for libnbd earlier today and it's pretty simple: https://github.com/libguestfs/libnbd/commit/c19a6fbae9a21a7d4693418706c59e81ed256875 However it's considerably more difficult to use libFuzzer with non-library code -- in this case nbdkit.

v1 was here: https://www.redhat.com/archives/libguestfs/2019-November/msg00003.html This version depends on: https://www.redhat.com/archives/libguestfs/2019-November/msg00004.html and this series: https://www.redhat.com/archives/libguestfs/2019-November/msg00009.html The delta has been reduced slightly because of changes made possible by cleaning up and fixing the quit path in nbdkit. It's

Hello List, I'm currently writing my own little optimization pass (on LLVM 6.0) and considered it a neat idea to fuzz it using llvm-opt-fuzzer, which in theory should be a ready-made tool for such jobs as far as I can tell, potentially helping me to find UB and Address issues in my pass. So I went ahead and followed the instructions in the build manual [1] to build LLVM's llvm-opt-fuzzer

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,

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:

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

Afternoon, I had an issue with trying to link a program with the DataFlowSanitizer functionality, this is from the libFuzzer project, and I was seeing: clang++ -fsanitize=address -fsanitize-coverage=edge test_fuzzer.cc Fuzzer*.o Undefined symbols for architecture x86_64: "_dfsan_create_label", referenced from: fuzzer::TraceState::DFSanCmpCallback(unsigned long, unsigned

> 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

So I was curious to start using the libFuzzer, but trying to follow along I got the following error: clang++ -fsanitize=address -fsanitize-coverage=edge test_fuzzer.cc Fuzzer*.o Undefined symbols for architecture x86_64: "_dfsan_create_label", referenced from: fuzzer::TraceState::DFSanCmpCallback(unsigned long, unsigned long, unsigned long, unsigned long long, unsigned long

Continuing my quixotic effort to get 'check-all' clean, I am seeing a Fuzzer failure on x86-64 Linux. Do any builders run fuzzer tests? FAIL: libFuzzer :: value-profile-mem.test (103 of 103) ******************** TEST 'libFuzzer :: value-profile-mem.test' FAILED ******************** Script: -- : 'RUN: at line 4'; /build/x86_64/./bin/clang --driver-mode=g++ -std=c++11

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

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

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

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