[LLVMdev] AddressSanitizer+CMake unittest question

[Chandler Carruth]

On Mon, Jun 25, 2012 at 7:38 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Mon, Jun 25, 2012 at 5:43 PM, Kostya Serebryany <kcc at google.com> wrote:
>>
>>
>>
>> On Mon, Jun 25, 2012 at 4:00 PM, Chandler Carruth <chandlerc at google.com> wrote:
>>>
>>> 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:
>>>
>>> 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.
>>> 2) 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.
>
>
> B is highly preferable.
> I.e.:
>   1. Build clang
>   2. Build asan-rt (doesn't not matter with which compiler)
>   3. build asan-rt-tests using clang from #1
> This is what we use now anyway.
> 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.

Ok... :: sigh :: Have to go and make this hard on me.


An additional constraint that would make this slightly easier: for the
tests which require instrumentation, could they strictly avoid
including headers outside of the test-helper headers? That is, none of
the libasan headers themselves.

This would make dependency management much much simpler, which seems
important given that it must be done manually.