[LLVMdev] AddressSanitizer+CMake unittest question

[Kostya Serebryany]

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

(answering parts at a time)
Agree. I am going to fix that now.


> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/60917df1/attachment.html>