<br><br><div class="gmail_quote">On Wed, Jul 11, 2012 at 3:06 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And one more question regarding ASan cmake build.<div>Currently unittests are fine, but regular "clang -faddress-sanitizer" is not:</div></blockquote><div><br></div><div>As a side note: I don't like that the current cmake machinery builds asan tests by explicitly passing libclang_rt.asan-x86_64.a. </div>
<div>IMO it needs to use "clang -faddress-sanitizer". </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br></div><div>current cmake build stores libclang_rt.asan-x86_64.a together with all the LLVM libs</div>
<div>(in $build_path/lib/libclang_rt.asan-x86_64.a), but the Clang driver looks for asan runtime</div><div>in clang resource dir: $build_path/lib/clang/3.2/lib/linux/libclang_rt.asan-x86_64.a). I can</div><div>try to find a way to how this can be fixed, but probably you can tell the answer right away.</div>

<div><br></div><div><div><div><div><div class="h5"><div class="gmail_quote">On Tue, Jun 26, 2012 at 11:41 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">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><div>On Tue, Jun 26, 2012 at 12:37 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>> wrote:<br>


><br>
><br>
><br>
> On Tue, Jun 26, 2012 at 11:06 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
>><br>
>> On Mon, Jun 25, 2012 at 7:38 AM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Jun 25, 2012 at 5:43 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Mon, Jun 25, 2012 at 4:00 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
>> >>><br>
>> >>> Context: I'm trying to implement support for ASan's unittest suite in CMake. This is ... quite challenging.<br>
>> >>><br>
>> >>> I think I can get it to work with one significant caveat: it will require manual dependency management. None of the automatic header tracking. I think this is fine in some cases, and not so fine in other cases. Let me explain.<br>


>> >>><br>
>> >>> It feels like these tests are really comprised of two distinct collections of tests:<br>
>> >>><br>
>> >>> 1) Those that rather directly test the ASan runtime. These do not rely upon the compiler instrumenting the code, and simply exercise the runtime library directly.<br>
>> >>> 2) Those that expect to be instrumented by the compiler, and exercise the runtime through GoogleTest's death tests on seemingly innocuous code.<br>
>> >>><br>
>> >>> For the first bucket, there is no problem. We should be able to handle these easily.<br>
>> >>><br>
>> >>> For the second bucket, this can be a bit tricky. It requires compiling the tests with a custom compiler and flags. Let's talk about the options for supporting this case.<br>
>> >>><br>
>> >>> A) We could require the host compiler to have support for -faddress-sanitizer, but ensure that the just-built runtime library is used rather than the host compiler's runtime library.<br>
>> >>> B) We can depend upon the Clang built in the same LLVM/Clang/CompilerRT checkout, and provide a custom compilation strategy to use it to instrument the unittest code.<br>
>> >>><br>
>> >>><br>
>> >>> Option A has fairly obvious problems: it introduces version skew into the equation, and would require a full bootstrap to test new instrumentation. However, it plays very nicely with the build system, requiring no special magic. It also would "Just Work" in the cross-compilation scenario, as much as any unittest would.<br>


>> >>><br>
>> >>> Option B avoids any version skew issues, but at the cost of requiring us to implement a "complete" custom compilation strategy for these source files. At the very least, this will not be portable and thus will only be enabled on a few platforms, and it will not get automatic header dependency tracking.<br>


>> ><br>
>> ><br>
>> > B is highly preferable.<br>
>> > I.e.:<br>
>> >   1. Build clang<br>
>> >   2. Build asan-rt (doesn't not matter with which compiler)<br>
>> >   3. build asan-rt-tests using clang from #1<br>
>> > This is what we use now anyway.<br>
>> > There could of course be dependencies between asan-rt and asan-rt-tests, but even worth, there could be dependencies between the instrumentation module in LLVM and asan-rt-tests.<br>
>><br>
>> Ok... :: sigh :: Have to go and make this hard on me.<br>
>><br>
>> An additional constraint that would make this slightly easier: for the<br>
>> tests which require instrumentation, could they strictly avoid<br>
>> including headers outside of the test-helper headers? That is, none of<br>
>> the libasan headers themselves.<br>
><br>
><br>
> Um, I guess so. AFAIR, it is true even now. I assume, including gtest headers is a<br>
> separate problem?<br>
<br>
</div></div>I can make that work through dirty dirty hacks. The various different<br>
sanitizer runtimes are actually harder to track and predict.<br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Alexey Samsonov, MSK</div><br>
</font></span></div></div></div>
</blockquote></div><br>