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