[LLVMdev] AddressSanitizer+CMake unittest question

[Kostya Serebryany]

On Wed, Jul 11, 2012 at 3:06 PM, Alexey Samsonov <samsonov at google.com>wrote:

> And one more question regarding ASan cmake build.
> Currently unittests are fine, but regular "clang -faddress-sanitizer" is
> not:
>

As a side note: I don't like that the current cmake machinery builds asan
tests by explicitly passing libclang_rt.asan-x86_64.a.
IMO it needs to use "clang -faddress-sanitizer".

--kcc


>
> current cmake build stores libclang_rt.asan-x86_64.a together with all the
> LLVM libs
> (in $build_path/lib/libclang_rt.asan-x86_64.a), but the Clang driver looks
> for asan runtime
> in clang resource dir:
> $build_path/lib/clang/3.2/lib/linux/libclang_rt.asan-x86_64.a). I can
> try to find a way to how this can be fixed, but probably you can tell the
> answer right away.
>
> On Tue, Jun 26, 2012 at 11:41 AM, Chandler Carruth <chandlerc at google.com>wrote:
>
>> On Tue, Jun 26, 2012 at 12:37 AM, Alexey Samsonov <samsonov at google.com>
>> wrote:
>> >
>> >
>> >
>> > 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?
>>
>> I can make that work through dirty dirty hacks. The various different
>> sanitizer runtimes are actually harder to track and predict.
>>
>
>
>
> --
> Alexey Samsonov, MSK
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120711/e9929ca6/attachment.html>