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>
Kostya Serebryany
2012-Jul-11 17:03 UTC
[LLVMdev] AddressSanitizer+CMake unittest question
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>
On Wed, Jul 11, 2012 at 10:03 AM, Kostya Serebryany <kcc at google.com> wrote:> > > 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". >Why? These are internal tests, and I think it is reasonable to use internal implementation details to make them work. I'm not saying we can't get there, I think we can, but I think it may be somewhat more annoying than you might imagine to get there in the short term. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120711/57861a51/attachment.html>