similar to: -sanitizer-coverage-prune-blocks=true and LibFuzzer

Hello, Is this reproducible? > Fuzzing is a probabilistic business and one or even two runs don't prove > much. > I've reproduced the behavior on two different machines. Attached is a script to do so. To use the script, - create an empty folder and copy both prune-blocks.sh and ff-http-parser.sh in there - ensure clang and clang++ are in your $PATH - cd /path/to/prune-blocks.sh

> On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Exciting! > > (btw, I'd prefer libfuzzer at googlegroups.com <mailto:libfuzzer at googlegroups.com> for such discussions, please start new topics there) You mean a LLVM library has a separate mailing-list? Why? — Mehdi > > I can reproduce this too, but

> On Sep 21, 2016, at 12:56 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Wed, Sep 21, 2016 at 12:32 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:

> On Sep 21, 2016, at 1:25 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Wed, Sep 21, 2016 at 12:58 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Sep 21, 2016, at 12:56 PM, Kostya Serebryany <kcc at google.com <mailto:kcc at google.com>> wrote: >> >> >>

Thank you, kcc. I am unsure if I misunderstand your reply. It seems that trace-bb, rather than trace-pc, fits better for my problem, given that my instrumentation is to put before each conditional statement. Do I misunderstand something here? " Tracing basic blocks <http://clang.llvm.org/docs/SanitizerCoverage.html#id11> With -fsanitize-coverage=trace-bb the compiler will insert

Hi, all I want to instrument a program automatically so that it prints "hello" before each conditional statement. For example, consider the function P below. int P(int x) { if (x<3) if (x>0) return 1; return 0; } Let P_instrum be the instrumented version of P. It is expected that: -- P_instrum(1) prints two "hello"s --

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 Tue, Aug 11, 2015 at 7:25 PM, Kostya Serebryany <kcc at google.com> wrote: > ... >> So if I'm seeing tens of thousands of distinct test files, that >> represents tens of thousands of distinct edges? >> > > In the extreme case -- yes. > However usually a single file covers more than one unique edge. > Also, if you are running the fuzzer in parallel

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

Hmmm that is a funny sequence. I know the .cfi directives are represented as pseudo-instructions, but they should not be causing us to emit .loc directives. They have no effect on the .text section so probably they should just be excluded from emitting a location, same as DBG_VALUE is excluded. Also I believe the label there is unnecessary, but that's a separate issue. Regarding "how

There is already –mllvm –use-unknown-locations which ought to trigger this. Don't need my patch. --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 4:08 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Libfuzzer depending on uninitialized debug info On Thu, Dec 1, 2016 at 3:37 PM, Robinson, Paul <paul.robinson at

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,

On Fri, Dec 2, 2016 at 5:42 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > I've determined that the "pesky" .loc is indeed because of the .cfi > directive that comes immediately after it. Some of the CFI instructions > have source locations, some don't. But, emitting a source location for a > CFI instruction is inappropriate. It's easy enough to

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

(2) cause CFI instructions not to emit any .loc directives; done in r289256, plus r289288 (3) file a bug to have someone audit LoopVectorizer.cpp to see whether it is using SetCurrentDebugLocation in the right places; haven't done that part yet (4) reapply my "line 0" patch, which will be the 3rd attempt. r289468 Please ping me when you do (4). Also, will there be a flag to disable

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

On Wed, Jul 12, 2017 at 11:30 AM, George Karpenkov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I already forgot why we decided not to move the code to compiler-rt. > > This would solve at least this problem. > Since we now have -fsanitize=fuzzer it will actually be pretty natural. > > > Licensing concerns, compiler-rt has a different license. > > BTW