Context: I’m trying to implement support for ASan’s unittest suite in CMake. This is … quite challenging.
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.
It feels like these tests are really comprised of two distinct collections of tests:
- 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.
- Those that expect to be instrumented by the compiler, and exercise the runtime through GoogleTest’s death tests on seemingly innocuous code.
For the first bucket, there is no problem. We should be able to handle these easily.
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.
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.
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.
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.
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.
I can pursue either of these options, but I’d like to know which the ASan folks would be most interested in working with.
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.