<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 9:38 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div class=""><div>
On Feb 12, 2014, at 11:43 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Feb 13, 2014 at 11:10 AM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>
On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hi, <div><br></div><div>Justin is making nice commits for llvm-cov, so I thought we may continue this discussion now. </div>
<div>The quick-and-dirty implementation of coverage (in asan) is getting some early users and they seem to be happy.</div>
<div>AsanCoverage allows to collect per-function or per-basic-block coverage (booleans only, no counters) at a very low cost:</div><div>1% for per-function and 20% for per-basic-block: <a href="https://code.google.com/p/address-sanitizer/wiki/AsanCoverage" target="_blank">https://code.google.com/p/address-sanitizer/wiki/AsanCoverage</a> </div>
<div>The output format is very simple and does not require any external tool (other than 56 lines in python) to handle it.</div><div>So, I was wondering it some similar functionality could be included as part of llvm-cov effort. </div>
<div>Also, do you have some documentation about the llvm-cov (how it works, what is the performance, etc)?</div></div></blockquote><div><br></div></div>Our recent work on llvm-cov has been pretty limited in scope. We’ve gotten it to work as a drop-in replacement for the old version of gcov that we had from gcc-4.2. There are still a few minor differences, but it generally seems to be working well.</div>
<div><br></div><div>As we discussed at the dev meeting, I want to hook up our PGO instrumentation to be used for coverage as well, but so far, our focus has been on the PGO side and there is nothing implemented for coverage yet. Once we start on that, I plan to extend llvm-cov to be the command line interface for viewing the coverage data. If you would like to teach it to display the AsanCoverage data as well, that seems like a good idea.</div>
</div></blockquote><div><br></div><div>I'd rather prefer to have functionality similar to today's AsanCoverage in the main "LLVM coverage", whatever that is.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"> Just be careful not to break anything for the old-style gcov support.</div></blockquote><div><br></div><div>Hm. Is that the long term goal? </div><div>My impression was that gcov is broken by design and beyond repair and we wanted something new that can scale.</div>
<div>Or you are talking only about the gcov file format which we want to keep for legacy reasons even if the files will be generated somehow differently? </div></div></div></div></blockquote><div><br></div></div>gcov and llvm-cov are just tools to view the coverage data.</div>
<div><br></div><div>We definitely want llvm-cov to continue to read the gcov-style file format, and we also need it to continue to support all the same things as gcov (at least the old gcc-4.2 version) for the sake of compatibility. I’m suggesting that we add new features to teach it to read the data files produced by AsanCoverage and (eventually) the -fprofile-instr-generate data.</div>
</div></blockquote><div><br></div><div>Ok, I see.</div><div>Then my question: will there be any objection if I disentangle AsanCoverage from ASan and make it a separate LLVM phase with the proper clang driver support?</div>
<div>Or it will be an unwelcome competition with the planned clang coverage?</div><div><br></div><div>Thanks! </div><div>--kcc</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div class=""><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div> There are various coverage tools out there that wrap around gcov, and we need to be careful not to break them.</div><div><br></div><div><div><blockquote type="cite"><div dir="ltr">
<div><br></div><div>BTW, would a 5-minute lightning talk about AsanCoverage be interesting at LLVM Euro 2014?</div></div></blockquote><div><br></div></div>I’d be interested in that, but I haven’t been involved at all with planning LLVM Euro, so someone else will have to answer that.</div>
</div></blockquote><div><br></div><div>I'll send a proposal.</div><div><br></div><div>--kcc </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br><blockquote type="cite"><div dir="ltr">
<div><br></div><div>Thanks, </div><div><br></div><div>--kcc </div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Nov 14, 2013 at 5:42 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Bob, Justin,<div><br></div><div>I've just committed a poor man's coverage implementation that works with asan. </div><div><a href="http://llvm.org/viewvc/llvm-project?rev=194701&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=194701&view=rev</a><br>
</div><div><a href="http://llvm.org/viewvc/llvm-project?rev=194702&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=194702&view=rev</a><br></div><div>It provides only function-level boolean coverage (i.e. no counters, just "visited or not"),</div>
<div>but is very fast and very simple (no extra sections to the binary file, etc)</div><div>I've tried it for Chrome's content_shell (huge and heavy binary) and the overhead </div><div>is negligible at both run-time and shutdown-time.</div>
<div><br></div><div>We'll be evaluating this implementation and collecting usage stats.</div><div>Maybe we want to implement something simple like this in the Clang coverage.</div><div><br></div><div>--kcc </div></div>
</blockquote></div><br></div></div>
</blockquote></div><br></div></div></blockquote></div><br></div></div>
</blockquote></div><br></div></div></blockquote></div><br></div></div>