<div dir="ltr">I've built chromium with "<span style="font-family:arial,sans-serif;font-size:13px"> -fprofile-instr-</span><span style="font-family:arial,sans-serif;font-size:13px">generate -fsanitize=address</span>" -- the performance looks good!<div>
The file format from r198638 is indeed r<span style="font-family:arial,sans-serif;font-size:13px">udimentary.</span><div>Do you already know how the real output format will look like?</div></div><div><br></div><div>Just to summarize what I think is important: </div>
<div> - minimal size on disk, minimal amount of files</div><div> - minimal i/o while writing to disk, no lockf or some such</div><div> - separate process produces separate file(s)</div><div> - fast merging of outputs from different runs of the same binary</div>
<div> - only the coverage output files and the binary (+DSOs) are required to "symbolize" the coverage data (map the data to file names & line numbers)</div><div><br></div><div>Ideally, symbolizing the cov data will use the debug info in the binary (i.e. llvm-symbolizer, addr2-line or atos),</div>
<div>this is what we've done in AsanCov, but I don't see a clean way to make it work with counters...</div><div><br></div><div>--kcc </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 2:08 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ah, that's -fprofile-instr-generate</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 2:03 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Tue, Feb 18, 2014 at 10:15 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">Our instrumentation code is basically done now, so you can try it out and compare the performance. Just build with -finstr-profile-generate. </div>
</blockquote><div><br></div></div><div>Is this in trunk?</div><div><div>clang-3.5: error: unknown argument: '-finstr-profile-generate'</div></div><div><br></div><div>--kcc</div><div><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">You may want to hack the compiler-rt code in lib/profile/PGOProfiling.c to disable writing the output, since the current implementation is pretty naive.<div><br></div><div>If it turns out as you suggest, and the different kinds of instrumentation serve different purposes, then I think it would make sense to do both.</div>
<div><div><div><br><div><div>On Feb 18, 2014, at 3:13 AM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Regarding performance, I've made a simple coverage with counters and compared it with AsanCoverage.<div>
<br></div><div>AsanCoverage produces code like this:</div><div><div>mov 0xe86cce(%rip),%al</div>
<div>test %al,%al</div><div>je 48b4a0 # to call __sanitizer_cov</div><div>...</div><div>callq 4715b0 <__sanitizer_cov><br></div><div><br></div><div>A simple counter-based thing (which just increments counters and does nothing else useful) produces this: </div>
<div>incq 0xe719c6(%rip)<br></div><div><br></div><div>The performance is more or less the same, although the issue with false sharing still remains</div><div> (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html</a>)</div>
<div><br></div><div>Do you have any more details about the planned clang coverage? </div><div><br></div><div>Thanks, </div></div><div><br></div><div>--kcc </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Feb 18, 2014 at 1:00 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"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Tue, Feb 18, 2014 at 12:20 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><br>
On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
> 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?<br>
> Or it will be an unwelcome competition with the planned clang coverage?<br>
<br>
</div>I don’t view it as a competition, but assuming that we both succeed in our plans, LLVM would then end up with two very similar solutions for code coverage. Does it really make sense to have two?</blockquote><div><br>
</div></div></div><div>It depends. If the two will indeed have the same functionality -- then no.</div><div>My understanding about your plans is that the upcoming coverage will provide "counters" (== how many times a bb/edge was executed).</div>
<div>AsanCoverage produces booleans (== 1, iff a function/bb was executed), which is less information, but faster.</div><div>How much faster -- I can't tell w/o your performance numbers.</div><div>For our early users the performance is critical and booleans are sufficient. </div>
<div><br></div><div>If we end up needing both variants, we may want to keep them similar from user perspective, e.g. have flag combinations like these:</div><div>-coverage=per-edge,counter<br></div><div>-coverage=per-function,counter</div>
<div>-coverage=per-block,counter<br></div><div><div>-coverage=per-function,boolean</div><div>-coverage=per-block,boolean<br></div></div><div><br></div><div> --kcc<br></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>