<br><br><div class="gmail_quote">On Mon, Aug 1, 2011 at 12:01 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@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 class="gmail_quote">Any updates on this?</div><div class="gmail_quote"><br></div><div class="gmail_quote">In particular, I'd like to see concrete patches proposed for review and inclusion into LLVM. I think having actual patches on the table and under review will help a great deal. Kostya, let me know if I can help prepare them. </div>
</blockquote><div><br></div><div>Ok, I'll send the first (small) patch shortly. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
A few general comments as well inline...</div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><div class="im">On Tue, Jul 26, 2011 at 1:57 AM, 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 class="gmail_quote"><div>On Tue, Jul 26, 2011 at 10:20 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br>
On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote:<br>
<br>
> Hi,<br>
> What would be our next steps in getting ASan into the LLVM trunk?<br>
> I'd like to do it in two steps, first for the LLVM part with minimal tests and then for the run-time library and all tests.<br>
> The current ASan's source repository will probably stay the primary home for the run-time library and tests as we plan to use it in non-LLVM environments.<br>
><br>
<br>
</div>Hi Kostya,<br>
<br>
I haven't had a chance to look at your patch yet, I'm backed up on "big patches".  Did you see my review of the safecode patch here?<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110718/124515.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110718/124515.html</a><br>
<br>
I expect to have similar concerns and suggestions for your patch,<br></blockquote><div><br></div></div><div>Hi Chris, </div><div><br></div><div>Thanks for the reply. </div><div>Indeed, some of your comments to safecode patch apply here. </div>


<div><br></div><div>Codingstyle: I'll try to cleanup as much as I can today. </div><div>Do you have any lint-like tool that checks for llvm coding style (similar to <a href="http://google-styleguide.googlecode.com/svn/trunk/cpplint/" target="_blank">cpplint</a>)? </div>

</div></blockquote><div><br></div></div><div>I don't know of any effective ones. Kostya, maybe you can send the code by myself and/or Nick to help walk through it for style issues?</div><div class="im"><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>Documentation: everything is in the wiki. The main pages are:</div><div><div><a href="http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer" target="_blank">http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer</a></div>


<div><a href="http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm" target="_blank">http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm</a></div></div></div></blockquote><div><br>

</div></div><div>It would be good to have these written up in HTML for easy inclusion in the existing LLVM documentation tree. This tree is checked in along side the code itself. However, contributing snapshots of the documentation from the wiki page could likely occur in follow-up patches. Alternatively, maybe Chris would be OK linking to these wiki pages from the primary LLVM documentation.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div>"who is going to maintain": my team at Google (in particular, myself and Alexander, in CC) are highly motivated to keep this working. </div>

</div></div>
"Do you have particular clients": the Chromium project is a <a href="http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html" target="_blank">very active</a> client.</blockquote><div><br></div>

</div><div>For reference, myself and others on my team at Google are working actively with Clang and LLVM and would be able to maintain, fix bugs, and update this. We also have a *very* large base of users that would be interested in the functionality.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>"The work can be decomposed into small and incremental pieces": </div><div>
   the <a href="http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/AddressSanitizer.cpp" target="_blank">LLVM part</a> is just 1000 LOC. If you still like it to be decomposed, we can do it in 3 parts: a) general instrumentation, b) redzones for stack, c) redzones for globals.</div>

</blockquote><div><br></div></div><div>I think breaking up the LLVM part would be very helpful. Can you break out the first part, and after a style cleanup mail the attached patch? Then the review for that can overlap with preparing the other 2 parts.</div>

<div><br></div><div><br></div><div>How do you plan to test this? It's important that there are regression tests in the LLVM suite that exercise the functionality independent of any runtime so that other developers can catch regressions. Also, unittests in the LLVM unittest tree would be nice as well.</div>
</div></blockquote><div><br></div><div>Currently, I have <a href="http://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fasan%2Ftests">tests</a> that work only with the run-time library. </div><div>I will definitely need tests that don't require run-time support. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div><br></div><div><br></div><div>Have you written a Clang patch to turn this functionality on and off? Looking at the wiki documentation shows one thing that gives me pause: you're using the -mllvm flag in Clang to directly pass options down to the LLVM layer. Also, it indicates the asan functionality defaults to on.</div>
</div></blockquote><div><br></div><div>Yes, I have clang patch that adds -fasan flag (off by default) to Linux and Mac (the run-time library doesn't work on other OSes yet). </div>The <a href="http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/clang.patch">patch</a> changes tools/clang/lib/Driver/Tools.cpp and tools/clang/include/clang/Driver/Options.td<div>
<br></div><div>The instrumentation pass has a bunch of flags which one can use via "-mllvm -asan-flag", but most of these flags should not be user-visible. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">
<div><br></div><div>Ideally all of this functionality would default to off, and be enabled via '-fasan' or even better '-faddress-sanitizer' in Clang. </div></div></blockquote><div><br></div><div>That's what I have now (-fasan). I slightly prefer -fasan over -faddress-sanitizer because the former is shorter. </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>That would match the behavior of '-fcatch-undefined-behavior', '-fmudflap', etc. If you want to expose the more fine grained flags to users that are mentioned on the wiki page, they could also have '-f...' Clang flags, but it seems unlikely that those are important.</div>
</div></blockquote><div><br></div><div>I will probably need a few more user-visible flags: [don't]instrument stack, [don't]instrument globals, [don't]instrument reads.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">
<div><br></div><div><br></div><div>What's your expected plan for the runtime library? Is that something you would be interested in contributing to the LLVM project proper? If so, I'd be interested in where Chris thinks that should go... in the LLVM runtimes tree? In a separate LLVM project?</div>
</div></blockquote><div><br></div><div>I'd like to be able to keep the run-time completely separate from the rest of LLVM so that the same library could be used in other environments. </div><div>This of course does not prevent us from having the library sources in the LLVM tree.</div>
<div><br></div><div>--kcc </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div><br></div><div>Anyways, thanks for working on integrating this back into LLVM!</div><div>-Chandler</div></div>
</blockquote></div><br>