search for: fsanitizer

(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

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:

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:

Hi All, Chandler, After listening to Chandlers presentation at Going native 2013, I think "lld" should add a buildbot configuration to turn on building lld with -fsanitize options and have buildbot configurations to run on * darwin * linux (ubuntu). I was not really sure on if llvm changes use a buildbot with the -fsanitize options turned on / how stable the llvm libraries are when

There are existing Darwin and Win7 builders, and a few Debian configs that also build lld. I'd support enabling the sanitizers on these builds as is. Also, tsan especially because lld uses threads. If you'd like an Ubuntu bot, somebody is going to have to provide one. Alex On Sep 6, 2013, at 2:27 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi All, Chandler, >

> 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

Hi all, I was trying to compile dfsan with wget. (Just enabling the dfsan feature, without actually making changes to the source code) Without dfsan, I am able to compile and run wget 1.19.5 (available at https://ftp.gnu.org/gnu/wget/wget-1.19.5.tar.gz). But when compiled with dfsan, it encountered a null pointer dereference error. Following an old post:

I get some failing tests from compiler-rt. FAIL: cfi :: cross-dso/stats.cpp (30831 of 30893) ******************** TEST 'cfi :: cross-dso/stats.cpp' FAILED ******************** Script: -- /usr/local/google/home/prazek/llvm-build-release/./bin/clang -fuse-ld=gold -flto -fsanitize=cfi -fwhole-program-vtables --driver-mode=g++ -fsanitize-cfi-cross-dso -fvisibility=default -DSHARED_LIB -fPIC

Hi Alex, + Galina Ubuntu/Debian should work as well, I wanted one flavor where lld could be built on linux platform. I will want to have a seperate buildbot to seperate failures if any due to the fsanitize options. Do you know if llvm itself gets tested as a complete build with the fsanitize options ? Enabling tsan seems to be a good idea too. Thanks Shankar Easwaran On 9/8/2013 10:22

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

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

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

I am working of using libfuzzer and asan to test out a third-party library. As demonstrated in the tutorial, I wrote a fuzz target to fuzz a specific function in the library. The fuzz target is then linked to the library and compiles clean and I do see some tests generated by the fuzzer. However, I have some questions regarding the "right" way to go about doing this. I have doubts that

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

Hello all! (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically, '-fsanitize=null'. You can see an example of the assert in this 26-line C++ file here: https://godbolt.org/g/Gw9UZq Note that

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:

> I think your best bet for controlling code bloat is to compile with > -fsanitize=undefined -fsanitize-trap=undefined. Also you may not need all of UBSan's checks at the same time -- so pick and choose among its checks using the finer-grained flags. If you're really stuck against a hard limit on code size, try applying UBSan to a subset of files in your project at a time. John

On 5/12/2018 9:23 PM, Philip Reames via llvm-dev wrote: > Fair warning, the following is a devil's advocate position, but it's > also a serious question. > > Given the entire point of this flag appears to be bug mitigation, why > not frame this as a sanitizer?  If we had a hypothetical > -fsanitize=dereference which tried to catch dereferenced pointers > derived

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

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,