<div dir="ltr"><div>Chris, </div>[I missed this message, thanks glider to pointing me to it]<div><br></div><div>Do you want a general mechanism or just coverage? </div><div>The general mechanism could make sense for general things (just like gcc's -finstrument-functions, but at BB level),</div>
<div>but it is less suitable for coverage for performance reasons -- calling a function per every block is expensive. </div><div><br></div><div>If you want fuzzing with genetic algorithms take a look here:</div><div><a href="https://code.google.com/p/address-sanitizer/wiki/AsanCoverage">https://code.google.com/p/address-sanitizer/wiki/AsanCoverage</a><br>
</div><div>We are already doing this kind of things with asan :) </div><div>And asan already supports blacklists. </div><div><br></div><div>--kcc </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 12:54 AM, Christian Holler <span dir="ltr"><<a href="mailto:choller@mozilla.com" target="_blank">choller@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello all,<br>
<br>
below is a proposal to include LLCov, a simple but helpful little tool<br>
based on LLVM/Clang, into the main LLVM code.<br>
<br>
Tl;dr: It's a module pass that instruments basic blocks with calls to an<br>
external function, and it can be used for various things, including<br>
(live!) basic block coverage.<br>
<br>
<br>
I'm looking forward to hear opinions on this :)<br>
<br>
<br>
Best,<br>
<br>
Chris<br>
<br>
<br>
=== Problem description ===<br>
<br>
Code coverage always has been considered an important aspect in testing.<br>
Especially for automated testing (e.g. fuzzing), coverage is a<br>
requirement for success. Some recent fuzzing research is going into the<br>
direction of genetic algorithms where coverage can be a part of the<br>
fitness function.<br>
However, applying this all to a large codebase in a practical way is a<br>
complex endeavor. Popular code coverage tools like  GCov are not exactly<br>
designed to be used to obtain coverage while the  program is running.<br>
Since we want to make decisions based on coverage  without terminating<br>
the program though (mainly for performance reasons but depending on the<br>
type of fuzzing also because one would like to  alter the mutation<br>
strategy mid-fuzzing), we need to get coverage  feedback live when it<br>
happens. Furthermore, we are often not interested in all of the<br>
coverage. Often, a particular portion of the code is targeted and the<br>
rest (which is the majority) would only slow us down if instrumented.<br>
<br>
=== Proposed solution ===<br>
I propose to include LLCov into the main LLVM tree. LLCov is implemented<br>
as a module pass and allows to selectively instrument code portions for<br>
basic block coverage measurement (or any other task that should be<br>
performed per basic block). It can  instrument based on a combination of<br>
black- and whitelist that works based on files, lines or functions. All<br>
of the instrumented code calls an arbitrary external function per basic<br>
block (that is, per control flow node). This external function can do<br>
whatever the tester wants it to do. The simplest task would be to output<br>
coverage information on stderr and have the fuzzer collect it there. It<br>
could also provide the information over a network socket though.<br>
<br>
=== Current status of the tool ===<br>
The current LLCov code is maintained at <a href="https://github.com/choller/LLCov" target="_blank">https://github.com/choller/LLCov</a><br>
and consists of the main LLCov.cpp file, implementing the module pass,<br>
as well as two patches (one integrating the LLVM pass, the other<br>
patching the Clang frontend to support the necessary compiler flag and<br>
to link the runtime). Over the time, the module pass itself only<br>
required little adjustment (e.g. some includes changed), but rebasing<br>
the patches for the frontend typically required manual work.<br>
<br>
=== Alternatives ===<br>
One alternative would be to add an interface such that the changes<br>
required to integrate this and other passes (especially into the Clang<br>
frontend), can be made dynamically. I'm not sure if this is possible though.<br>
Another alternative would be to add this functionality to the GCov pass,<br>
but I am not sure if that is easily doable given the way GCov typically<br>
works.<br>
<br>
<br>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>