done, r145463<div><br></div><div>Will continue working on the integration with the build system, etc. </div><div>Expect more commits :) </div><div><br></div><div>--kcc </div><div><br><br><div class="gmail_quote">On Tue, Nov 29, 2011 at 12:32 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="HOEnZb"><div class="h5">On Mon, Nov 28, 2011 at 1:15 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>

><br>
><br>
> On Thu, Nov 24, 2011 at 7:27 AM, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>
>><br>
>> Quick answers, I'm on txgiving break this week and not doing any real<br>
>> work, but I will be doing more compiler-rt work when I get back<br>
>> (initially focused at getting profile libs to come from compiler-rt on<br>
>> Linux et al).<br>
>><br>
>> On Wed, Nov 16, 2011 at 9:24 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
>> > Hi Daniel,<br>
>> > Chris suggested to talk to you about committing the AddressSanitizer<br>
>> > (asan)<br>
>> > run-time into the llvm tree (llvm-project/compiler-rt).<br>
>> > Questions:<br>
>> > - What is the preferred name for the directory? (asan? libasan?<br>
>> > address_sanitizer? AdressSanitizer?)<br>
>><br>
>> I don't care. lib/asan seems perfectly reasonable to me, with a README<br>
>> explaining what the module is for.<br>
><br>
><br>
> So, it will be a sibling of lib/profile. Makes sense.<br>
><br>
>><br>
>><br>
>> > - Should the asan run-time use cmake, or just make, or what? The build<br>
>> > is a<br>
>> > bit tricky, especially for tests. We currently use make.<br>
>><br>
>> The only build system I care about for compiler-rt is the one in make.<br>
>> It's quite a crazy set up, although there is a reason for it to be as<br>
>> complicated as it is. I can help (and/or) do the asan integration into<br>
>> the compiler-rt make build.<br>
><br>
><br>
> Yea, I may need your help, probably after the files are committed.<br>
<br>
</div></div>No problem!<br>
<div class="im"><br>
>><br>
>><br>
>> > - How would you suggest to do the code review?<br>
>> >    The code of the run-time is ~5<br>
>> ><br>
>> > KLOC. <a href="http://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fasan" target="_blank">http://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fasan</a><br>
>> >    The Apple-specific part may make some Apple experts cry (or maybe<br>
>> > not).<br>
>> >    The code uses google's coding style, which is similar, but not<br>
>> > equivalent<br>
>> > to the LLVM's one. We check it using cpplint before commits.<br>
>><br>
>> I personally would like to see it be in LLVM style, but the rest of<br>
>> compiler-rt isn't really that way, so I don't think this is a blocker.<br>
>><br>
>> Unless anyone objects, I think we should just bring the code in as is<br>
>> so that ASAN works, and if people want to do more thorough review that<br>
>> can happen post commit.<br>
><br>
><br>
> Do I just start committing or someone still wants to make a pre-review?<br>
<br>
</div>No one has objected, so I vote to just commit it into lib/asan and<br>
work from there.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - Daniel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>><br>
>><br>
>> >    LLVM license is used.<br>
>> >    The tests are ~2.5 KLOC; most of the tests require the clang compiler<br>
>> > with -faddress-sanitizer switch.<br>
>> >    If possible, I'd prefer not to review the patch in a usual way (too<br>
>> > big),<br>
>> > but instead have the comments to the files<br>
>> ><br>
>> > in <a href="http://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fasan" target="_blank">http://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fasan</a><br>
>> >    Or, alternatively, commit everything as is and then iterate over<br>
>> > individual files.<br>
>> > - The run-time library uses a couple of third_party files (BSD license)<br>
>> > to<br>
>> > parse process mapping.<br>
>> >   W/o these files asan will work, but will not produce symbolizable<br>
>> > traces.<br>
>> >   Can we include these files as as in a separate directory? (They may be<br>
>> > useful for other tools as well)<br>
>><br>
>> Let's try to include the bits with extra licenses in subdirectories of<br>
>> lib/asan. If someone wants to reuse them later we can find a different<br>
>> way to factor things, I don't see a reason to worry about it now.<br>
><br>
><br>
> Ok.<br>
><br>
> On a related note: lib/asan might benefit from reusing some of the lldb code<br>
> (symbolizer).<br>
><br>
>><br>
>><br>
>> ><br>
>> >   <a href="http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/sysinfo.cc" target="_blank">http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/sysinfo.cc</a><br>
>> > - Yet another piece of third-party code (mit license) is used for<br>
>> > Apple-specific work (function overriding). Same question as above apply.<br>
>> ><br>
>> ><br>
>> >  <a href="http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/mach_override.c" target="_blank">http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/mach_override.c</a><br>
>> > - test-specific: can I rely on gtest being installed? (fresh version is<br>
>> > required).<br>
>><br>
>> Compiler-rt doesn't currently have a very good test set up. You'll<br>
>> probably have to find a way to shoehorn this in for your own testing<br>
>> initially, but we can try and work out a way to integrate it more<br>
>> properly...<br>
><br>
><br>
> ok.<br>
><br>
><br>
> Thanks!<br>
><br>
> --kcc<br>
</div></div></blockquote></div><br></div>