<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>