[LLVMdev] AddressSanitizer+CMake unittest question (original) (raw)

Alexey Samsonov samsonov at google.com
Wed Jul 11 04:06:20 PDT 2012

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

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/cb7f06be/attachment.html>

More information about the llvm-dev mailing list