[LLVMdev] AddressSanitizer+CMake unittest question

[Alexey Samsonov]

On Tue, Jun 26, 2012 at 11:06 AM, Chandler Carruth <chandlerc at google.com>wrote:

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

Um, I guess so. AFAIR, it is true even now. I assume, including gtest
headers is a
separate problem?


>
> This would make dependency management much much simpler, which seems
> important given that it must be done manually.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120626/3a7814ed/attachment.html>