<div style="font-family: arial, helvetica, sans-serif"><font size="2">Hi CMake'ers,<div><br></div><div>See the email below from llvmdev. I was wondering whether there's a better way to solve this. Ideas?</div><div>
<br></div><div>Thanks!</div><div>/Manuel<br><div><br><div class="gmail_quote">On Mon, Jun 25, 2012 at 2:00 PM, 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 style="font-family:arial,helvetica,sans-serif"><font size="2">Context: I'm trying to implement support for ASan's unittest suite in CMake. This is ... quite challenging.<div>
<br></div><div>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.</div>
<div><br></div><div>It feels like these tests are really comprised of two distinct collections of tests:</div><div><br></div><div>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.</div>
<div>2) Those that expect to be instrumented by the compiler, and exercise the runtime through GoogleTest's death tests on seemingly innocuous code.</div><div><br></div><div>For the first bucket, there is no problem. We should be able to handle these easily.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div>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.</div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>I can pursue either of these options, but I'd like to know which the ASan folks would be most interested in working with.</div><div><br></div><div>Second, it would be extremely helpful to have a very firm separation between bucket #1 and bucket #2. Currently, there is one collection of tests clearly in bucket #1 (asan_noinst_test.cc), and plenty of tests clearly in bucket #2, but there seems to be quite a bit of overlap as well. For example, I would naively expect asan_interface_test.cc to not require instrumentation -- it almost exclusively directly calls the runtime. But it is currently being compiled with instrumentation by the Makefile.old, so I'm at a loss. Separating these two scenarios into at least separate files, and ideally linking them into two separate binaries would make everything much simpler. For example, bucket #2 shouldn't need to include any of ASan's header files, making it easier to manage manual dependencies if necessary.</div>
</font></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div></font></div>