<br><br><div class="gmail_quote">On Thu, Nov 24, 2011 at 7:27 AM, 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;">
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>
<div class="im"><br>
On Wed, Nov 16, 2011 at 9:24 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
</div><div class="im">> Hi Daniel,<br>
> Chris suggested to talk to you about committing the AddressSanitizer (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>
</div>I don't care. lib/asan seems perfectly reasonable to me, with a README<br>
explaining what the module is for.<br></blockquote><div><br></div><div>So, it will be a sibling of lib/profile. Makes sense. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> - Should the asan run-time use cmake, or just make, or what? The build is a<br>
> bit tricky, especially for tests. We currently use make.<br>
<br>
</div>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></blockquote><div><br></div><div>Yea, I may need your help, probably after the files are committed. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> - How would you suggest to do the code review?<br>
> The code of the run-time is ~5<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 not).<br>
> The code uses google's coding style, which is similar, but not equivalent<br>
> to the LLVM's one. We check it using cpplint before commits.<br>
<br>
</div>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></blockquote><div><br></div><div>Do I just start committing or someone still wants to make a pre-review? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><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 big),<br>
> but instead have the comments to the files<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) to<br>
> parse process mapping.<br>
> W/o these files asan will work, but will not produce symbolizable 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>
</div>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></blockquote><div><br></div><div>Ok. </div><div><br></div><div>On a related note: lib/asan might benefit from reusing some of the lldb code (symbolizer). </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><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>
> <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>
</div>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></blockquote><div><br></div><div>ok. </div><div> </div><div><br></div><div>Thanks! </div><div><br></div><div>--kcc </div></div>