<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. A few general comments as well inline...</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Jul 26, 2011 at 1:57 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com">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 class="im">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>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><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 class="im"><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>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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><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>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> </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>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><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><br></div><div>Ideally all of this functionality would default to off, and be enabled via '-fasan' or even better '-faddress-sanitizer' in Clang. 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><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><br></div><div>Anyways, thanks for working on integrating this back into LLVM!</div><div>-Chandler</div></div>