search for: dllvm_use_sanitize_coverage

...uilding 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 and -DLLVM_USE_SANITIZE_COVERAGE=On, which was working before: % cmake -GNinja \ -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On \ -DLLVM_ENABLE_WERROR=On \ -DLLVM_USE_SANITIZER=Address -DLLVM_USE_SANITIZE_COVERAGE=On \ -DCMAKE_C_COMPILER=$HOME/llvm-lkgc/bin/clang \ $HOME...

...9;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 and -DLLVM_USE_SANITIZE_COVERAGE=On, which >> was working before: >> >> % cmake -GNinja \ >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On \ >> -DLLVM_ENABLE_WERROR=On \ >> -DLLVM_USE_SANITIZER=Address -DLLVM_USE_SANITIZE_COVERAGE=On \ >> -DCM...

I decided to try out the fuzzer library and clang-fuzzer, but it doesn't seem to build for me. From the cmake files, I was pretty sure all I need to do is set -DLLVM_USE_SANITIZE_COVERAGE=ON, but with this I get a number of link errors for "lib/Fuzzer/test/LLVMFuzzer-CounterTest", for example: lib/libLLVMFuzzer.a(FuzzerLoop.cpp.o): In function `SetDeathCallback': /home/bogner/code/llvm/lib/Fuzzer/FuzzerLoop.cpp:31: undefined reference to `__sanitizer_set_death_cal...

...9;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 and -DLLVM_USE_SANITIZE_COVERAGE=On, which >> was working before: >> >> % cmake -GNinja \ >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On \ >> -DLLVM_ENABLE_WERROR=On \ >> -DLLVM_USE_SANITIZER=Address -DLLVM_USE_SANITIZE_COVERAGE=On \ >> -DCM...

...; 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 and -DLLVM_USE_SANITIZE_COVERAGE=On, which > >> was working before: > >> > >> % cmake -GNinja \ > >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On \ > >> -DLLVM_ENABLE_WERROR=On \ > >> -DLLVM_USE_SANITIZER=Address -DLLVM_USE_SANITIZE_COVERAG...

...er-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 and -DLLVM_USE_SANITIZE_COVERAGE=On, >>> which >>> >> was working before: >>> >> >>> >> % cmake -GNinja \ >>> >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On \ >>> >> -DLLVM_ENABLE_WERROR=On \ >>> >>...

...t;> >> 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 and -DLLVM_USE_SANITIZE_COVERAGE=On, >> >>> which >> >>> >> was working before: >> >>> >> >> >>> >> % cmake -GNinja \ >> >>> >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On \ >> >>> >>...

...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 and -DLLVM_USE_SANITIZE_COVERAGE=O >>>> n, >>>> >>> which >>>> >>> >> was working before: >>>> >>> >> >>>> >>> >> % cmake -GNinja \ >>>> >>> >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENA...

...> be > >>>>> >>> related). > >>>>> >>> >> > >>>>> >>> >> I'm building with a fresh top-of-tree clang and setting > >>>>> >>> >> -DLLVM_USE_SANITIZER=Address and > -DLLVM_USE_SANITIZE_COVERAGE=O > >>>>> n, > >>>>> >>> which > >>>>> >>> >> was working before: > >>>>> >>> >> > >>>>> >>> >> % cmake -GNinja \ > >>>>> >>> &...

...; >>> related). >>> >>>>> >>> >> >>> >>>>> >>> >> I'm building with a fresh top-of-tree clang and setting >>> >>>>> >>> >> -DLLVM_USE_SANITIZER=Address and >>> -DLLVM_USE_SANITIZE_COVERAGE=O >>> >>>>> n, >>> >>>>> >>> which >>> >>>>> >>> >> was working before: >>> >>>>> >>> >> >>> >>>>> >>> >> % cmake -GNinja \...

...n r270942 the time taken to run LibFuzzer's test became noticeably longer. I am building on * Arch Linux (4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux) * I am building libFuzzer and running its tests like so ``` CC=<new_clang> CXX=<new_clang++> cmake -DLLVM_USE_SANITIZE_COVERAGE=1 -DLLVM_USE_SANITIZER=Address -DCMAKE_BUILD_TYPE=RELEASE ../src/ && make check-fuzzer -j8 ``` where ``<new_clang>`` and ``<new_clang++>`` point to a recently built clang (llvm: r270960 , clang: r270962 , compiler-rt: r270949) which itself was compiled using gcc 6.1.1. In r270...

...zer's test became noticeably > longer. I am building on > > * Arch Linux (4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST > 2016 x86_64 GNU/Linux) > * I am building libFuzzer and running its tests like so > > ``` > CC=<new_clang> CXX=<new_clang++> cmake -DLLVM_USE_SANITIZE_COVERAGE=1 > -DLLVM_USE_SANITIZER=Address -DCMAKE_BUILD_TYPE=RELEASE ../src/ && > make check-fuzzer -j8 > ``` > > where ``<new_clang>`` and ``<new_clang++>`` point to a recently built > clang (llvm: r270960 , clang: r270962 , compiler-rt: r270949) which > itself was...

...xt+0x18f): undefined reference to > `std::__cxx11::basic_string<char, std::char_traits<char>, > std::allocator<char> >::~basic_string()' > > And I get similar errors if I try to build it using the LLVM CMake > generated makefiles (after running "cmake > -DLLVM_USE_SANITIZE_COVERAGE=1" in the LibFuzzer directory), in fact I > get errors that I need -std=c++11. Do I need to recompile *all* of > llvm as if I was going to fuzz LLVM just to get libfuzzer built? > > -- > greg > _______________________________________________ > LLVM Developers mailing list...

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

I have a project I want to do based on Libfuzzer. Is there a separate list for it or should I bring up any ideas for it here? What I have in mind is to fuzz Postgres. Trying to fuzz the SQL interpreter in general is not very productive because traditional fuzzers try to execute the entire program repeatedly and it has a fairly high startup and shutdown cost. Also the instrumentation-guided

FTR, I've disabled libcxx checkout on that particular bot <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer> to make it green. The problem remains, of course. :( On Sun, Dec 11, 2016 at 7:23 AM, James Knight <jyknight at google.com> wrote: > On Dec 11, 2016, at 3:33 AM, Eric Fiselier via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > So it

On Dec 11, 2016, at 3:33 AM, Eric Fiselier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > So it seems that libatomic went missing between build #1379 and #1380, so I don't think this is related to the -std=c++11 failure. Instead it seems likely that the compile test for -std=c++11 is failing due to mis-configuring -latomic. > > Can you confirm the bot has libatomic

...>> longer. I am building on >> >> * Arch Linux (4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST >> 2016 x86_64 GNU/Linux) >> * I am building libFuzzer and running its tests like so >> >> ``` >> CC=<new_clang> CXX=<new_clang++> cmake -DLLVM_USE_SANITIZE_COVERAGE=1 >> -DLLVM_USE_SANITIZER=Address -DCMAKE_BUILD_TYPE=RELEASE ../src/ && >> make check-fuzzer -j8 >> ``` >> >> where ``<new_clang>`` and ``<new_clang++>`` point to a recently built >> clang (llvm: r270960 , clang: r270962 , compiler-rt: r270949...

...om the rest of LLVM, >> missing those desired warnings/optimizations. >> >> Additionally, working with “runtimes” introduces some inherent >> restrictions. >> Namely: >> >> 4) Extra arguments to CMake will not be propagated. >> E.g. invoking `cmake … -DLLVM_USE_SANITIZE_COVERAGE=1` will not have any >> effect on the compilation of any project >> in “runtimes”. >> It’s not clear how those flags can be explicitly propagated. >> >> 5) In a similar vein to (4), additional flags to `ninja` will not be >> propagated. >> E.g. running “nin...

r247321 refactors the code so that it should build on Mac. I haven't actually tested it on Mac -- so please help me and send follow up patches if needed. check-fuzzer will still fail because some of the libFuzzer tests require dfsan. I'd use some help from someone with a Mac to modify lib/Fuzzer/test/CMakeLists.txt so that it does not run dfsan-dependent tests on Mac. Thanks, --kcc On