Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov <samsonov at google.com>wrote:> > On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov < > eugeni.stepanov at gmail.com> wrote: > >> On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> >> wrote: >> > When I build compiler-rt with clang 3.2, all lsan tests pass. The only >> > failing tests I see are in ubsan: >> > >> > Failing Tests (6): >> > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp >> > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp >> > UndefinedBehaviorSanitizer :: Integer/div-zero.cpp >> > UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp >> > UndefinedBehaviorSanitizer :: Integer/uadd-overflow.cpp >> > UndefinedBehaviorSanitizer :: Integer/usub-overflow.cpp >> > >> > >> > When I build with gcc 4.4.3, I need the changes below to get the source >> to >> > compile (and then the lsan tests fails). What are you all using to >> build >> > compiler-rt? are you developing on linux, osx or windows? Using gcc or >> > llvm? Which should I expect to work? Any buildbots running? >> >> > As Evgeniy said, we build compiler-rt on Linux and on Mac OS X, and run > tests for various sanitizers on our buildbots. > Note that CMake build system of compiler-rt uses host compiler to build > it. On Linux we use: > 1) gcc 4.6.3 > 2) tip-of-the-trunk Clang, > and tests pass under both of these. > > gcc 4.4.3 seems way too old, so in some sense we've dropped support for it > (you have to make changes, as old gcc is not > smart enough to make some POD variables thread-local). > > >> I think we build compiler-rt with the host compiler, except for >> Android. Which is usually a recently-built clang. n Linux, but we >> exercise osx build on our buildbots. >> We never build with compiler-rt not in projects/. >> Our bot scripts are here: >> >> https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave >> The bots itself are not publicly visible, we hope to change that soon. >> >> > >> > And lastly, are there build instructions to build the Android shared >> object? >> > Is there any way to build an android static lib? How about for >> arm-linux? >> >> Android runtime is special, we build it in a separate build tree >> configured with >> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake >> See buildbot_cmake.sh for details. >> >> > >> > Thanks, >> > Greg >> > >> > >> > diff --git a/lib/interception/interception.h >> > b/lib/interception/interception.h >> > index d50af35..1771d4e 100644 >> > --- a/lib/interception/interception.h >> > +++ b/lib/interception/interception.h >> > @@ -27,8 +27,8 @@ typedef __sanitizer::uptr SIZE_T; >> > typedef __sanitizer::sptr SSIZE_T; >> > typedef __sanitizer::sptr PTRDIFF_T; >> > typedef __sanitizer::s64 INTMAX_T; >> > -typedef __sanitizer::OFF_T OFF_T; >> > -typedef __sanitizer::OFF64_T OFF64_T; >> > +//typedef __sanitizer::OFF_T OFF_T; >> > +//typedef __sanitizer::OFF64_T OFF64_T; >> > >> > // How to add an interceptor: >> > // Suppose you need to wrap/replace system function (generally, from >> libc): >> > diff --git a/lib/lsan/lsan_allocator.cc b/lib/lsan/lsan_allocator.cc >> > index 9bf27b1..190dce8 100644 >> > --- a/lib/lsan/lsan_allocator.cc >> > +++ b/lib/lsan/lsan_allocator.cc >> > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, >> > AllocatorCache, >> > SecondaryAllocator> Allocator; >> > >> > static Allocator allocator; >> > -static THREADLOCAL AllocatorCache cache; >> > +static /*THREADLOCAL*/ AllocatorCache cache; >> > >> > void InitializeAllocator() { >> > allocator.Init(); >> > diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc >> > index 7435843..3e6adb6 100644 >> > --- a/lib/msan/msan_allocator.cc >> > +++ b/lib/msan/msan_allocator.cc >> > @@ -33,7 +33,7 @@ typedef LargeMmapAllocator<> SecondaryAllocator; >> > typedef CombinedAllocator<PrimaryAllocator, AllocatorCache, >> > SecondaryAllocator> Allocator; >> > >> > -static THREADLOCAL AllocatorCache cache; >> > +static /*THREADLOCAL*/ AllocatorCache cache; >> > static Allocator allocator; >> > >> > static int inited = 0; >> > >> > >> > >> > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> >> wrote: >> >> >> >> I blame this line in lsan/lit_tests/lit.cfg: >> >> >> >> # Setup attributes common for all compiler-rt projects. >> >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", >> >> "compiler-rt", >> >> "lib", "lit.common.cfg") >> >> >> >> >> >> On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com> >> >> wrote: >> >>> >> >>> >> >>> On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald <garious at gmail.com> >> >>> wrote: >> >>>> >> >>>> > it assumes that compiler-rt is checked out to >> >>>> > llvm/projects/compiler-rt. Apparently, this is a problem. >> >>>> >> >>>> I have a patch for this ready. I'll send it to you and llvm-commits. >> >>>> Most of the tests pass with "make check-all" but the recently-added >> lsan >> >>>> tests are all failing. Do those fail for you as well? If so, can >> we XFAIL >> >>>> them for now and try to keep the "make check-all" build clean? >> >>> >> >>> >> >>> Thanks! I'll take a look at the patch today. LSan tests work fine for >> me, >> >>> and we have them on our buildbot as well. What are the failures you >> see? >> >>> >> >>>> >> >>>> >> >>>> Thanks, >> >>>> Greg >> >>>> >> >>>> >> >>>> >> >>>> On Wed, May 22, 2013 at 9:39 PM, Alexey Samsonov < >> samsonov at google.com> >> >>>> wrote: >> >>>>> >> >>>>> Hi! >> >>>>> >> >>>>> The docs look strange to me - I don't indeed see any CMake support >> for >> >>>>> running compiler-rt tests. >> >>>>> Probably compiler-rt folks can comment on this... >> >>>>> I think you should run compilert-rt tests manually by smth. like >> >>>>> compiler-rt/test/Unit/test. >> >>>>> >> >>>>> CMake build system is able of running a bunch of sanitizer tests >> >>>>> (AddressSanitizer, ThreadSanitizer etc.), and it assumes that >> >>>>> compiler-rt is checked out to llvm/projects/compiler-rt. Apparently, >> >>>>> this is a problem. There was a patch that tried to address this, but >> >>>>> it never got committed. >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Wed, May 22, 2013 at 11:38 PM, Greg Fitzgerald < >> garious at gmail.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> Anybody working on porting the compiler-rt tests to cmake? >> >>>>>> >> >>>>>> The online documentation shows a preference for cmake and ctest, >> but >> >>>>>> the CMakeLists file has the comment "Currently the tests have not >> been >> >>>>>> ported to CMake, so disable this directory." How should we be >> running the >> >>>>>> test suite? >> >>>>>> >> >>>>>> http://compiler-rt.llvm.org/ >> >>>>>> >> >>>>>> My immediate issue is that "make check-all" fails in the cmake >> build >> >>>>>> when compiler-rt is outside the projects directory. When I point >> to >> >>>>>> compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still >> looks for >> >>>>>> lit.common.cfg within "projects/compiler-rt" instead of the >> external >> >>>>>> directory. I use similar CMake variables for Clang and Polly and >> have had >> >>>>>> no trouble. Any recommendations for how to fix? >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Greg >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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 >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Alexey Samsonov, MSK >> >> >> >> >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> _______________________________________________ >> 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/20130528/23c57fe8/attachment.html>
> Android runtime is special, we build it in a separate build treeconfigured with> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmakeThis worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory. But as you mentioned, we can build compiler-rt with a any recent version of gcc or clang. Here's the change I'm looking for: diff --git a/cmake/platforms/Android.cmake b/cmake/platforms/Android.cmake index 72849b1..5f732ce 100644 --- a/cmake/platforms/Android.cmake +++ b/cmake/platforms/Android.cmake @@ -11,8 +11,15 @@ # make <target> SET(CMAKE_SYSTEM_NAME Linux) + +IF(NOT CMAKE_C_COMPILER) SET(CMAKE_C_COMPILER ${CMAKE_BINARY_DIR}/../bin/clang) +ENDIF() + +IF(NOT CMAKE_CXX_COMPILER) SET(CMAKE_CXX_COMPILER ${CMAKE_BINARY_DIR}/../bin/clang++) +ENDIF() + SET(ANDROID "1" CACHE STRING "ANDROID" FORCE) SET(ANDROID_COMMON_FLAGS "-target arm-linux-androideabi --sysroot=${LLVM_ANDROID_TOOLCHAIN_DIR}/sysroot -B${LLVM_ANDROID_TOOLCHAIN_DIR} -mllvm -arm-enable-ehabi") On Tue, May 28, 2013 at 11:26 AM, Greg Fitzgerald <garious at gmail.com> wrote:> Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang > 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks > like everything works great, but that you just need to make those UB tests > 'unsupported' since they fail with "libclang_rt.ubsan was built without > __int128 support". > > Thanks, > Greg > > > > On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov <samsonov at google.com>wrote: > >> >> On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov < >> eugeni.stepanov at gmail.com> wrote: >> >>> On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> >>> wrote: >>> > When I build compiler-rt with clang 3.2, all lsan tests pass. The only >>> > failing tests I see are in ubsan: >>> > >>> > Failing Tests (6): >>> > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/div-zero.cpp >>> > UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/uadd-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/usub-overflow.cpp >>> > >>> > >>> > When I build with gcc 4.4.3, I need the changes below to get the >>> source to >>> > compile (and then the lsan tests fails). What are you all using to >>> build >>> > compiler-rt? are you developing on linux, osx or windows? Using gcc >>> or >>> > llvm? Which should I expect to work? Any buildbots running? >>> >>> >> As Evgeniy said, we build compiler-rt on Linux and on Mac OS X, and run >> tests for various sanitizers on our buildbots. >> Note that CMake build system of compiler-rt uses host compiler to build >> it. On Linux we use: >> 1) gcc 4.6.3 >> 2) tip-of-the-trunk Clang, >> and tests pass under both of these. >> >> gcc 4.4.3 seems way too old, so in some sense we've dropped support for >> it (you have to make changes, as old gcc is not >> smart enough to make some POD variables thread-local). >> >> >>> I think we build compiler-rt with the host compiler, except for >>> Android. Which is usually a recently-built clang. n Linux, but we >>> exercise osx build on our buildbots. >>> We never build with compiler-rt not in projects/. >>> Our bot scripts are here: >>> >>> https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave >>> The bots itself are not publicly visible, we hope to change that soon. >>> >>> > >>> > And lastly, are there build instructions to build the Android shared >>> object? >>> > Is there any way to build an android static lib? How about for >>> arm-linux? >>> >>> Android runtime is special, we build it in a separate build tree >>> configured with >>> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake >>> See buildbot_cmake.sh for details. >>> >>> > >>> > Thanks, >>> > Greg >>> > >>> > >>> > diff --git a/lib/interception/interception.h >>> > b/lib/interception/interception.h >>> > index d50af35..1771d4e 100644 >>> > --- a/lib/interception/interception.h >>> > +++ b/lib/interception/interception.h >>> > @@ -27,8 +27,8 @@ typedef __sanitizer::uptr SIZE_T; >>> > typedef __sanitizer::sptr SSIZE_T; >>> > typedef __sanitizer::sptr PTRDIFF_T; >>> > typedef __sanitizer::s64 INTMAX_T; >>> > -typedef __sanitizer::OFF_T OFF_T; >>> > -typedef __sanitizer::OFF64_T OFF64_T; >>> > +//typedef __sanitizer::OFF_T OFF_T; >>> > +//typedef __sanitizer::OFF64_T OFF64_T; >>> > >>> > // How to add an interceptor: >>> > // Suppose you need to wrap/replace system function (generally, from >>> libc): >>> > diff --git a/lib/lsan/lsan_allocator.cc b/lib/lsan/lsan_allocator.cc >>> > index 9bf27b1..190dce8 100644 >>> > --- a/lib/lsan/lsan_allocator.cc >>> > +++ b/lib/lsan/lsan_allocator.cc >>> > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, >>> > AllocatorCache, >>> > SecondaryAllocator> Allocator; >>> > >>> > static Allocator allocator; >>> > -static THREADLOCAL AllocatorCache cache; >>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>> > >>> > void InitializeAllocator() { >>> > allocator.Init(); >>> > diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc >>> > index 7435843..3e6adb6 100644 >>> > --- a/lib/msan/msan_allocator.cc >>> > +++ b/lib/msan/msan_allocator.cc >>> > @@ -33,7 +33,7 @@ typedef LargeMmapAllocator<> SecondaryAllocator; >>> > typedef CombinedAllocator<PrimaryAllocator, AllocatorCache, >>> > SecondaryAllocator> Allocator; >>> > >>> > -static THREADLOCAL AllocatorCache cache; >>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>> > static Allocator allocator; >>> > >>> > static int inited = 0; >>> > >>> > >>> > >>> > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> >>> wrote: >>> >> >>> >> I blame this line in lsan/lit_tests/lit.cfg: >>> >> >>> >> # Setup attributes common for all compiler-rt projects. >>> >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", >>> >> "compiler-rt", >>> >> "lib", "lit.common.cfg") >>> >> >>> >> >>> >> On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com >>> > >>> >> wrote: >>> >>> >>> >>> >>> >>> On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald <garious at gmail.com> >>> >>> wrote: >>> >>>> >>> >>>> > it assumes that compiler-rt is checked out to >>> >>>> > llvm/projects/compiler-rt. Apparently, this is a problem. >>> >>>> >>> >>>> I have a patch for this ready. I'll send it to you and >>> llvm-commits. >>> >>>> Most of the tests pass with "make check-all" but the recently-added >>> lsan >>> >>>> tests are all failing. Do those fail for you as well? If so, can >>> we XFAIL >>> >>>> them for now and try to keep the "make check-all" build clean? >>> >>> >>> >>> >>> >>> Thanks! I'll take a look at the patch today. LSan tests work fine >>> for me, >>> >>> and we have them on our buildbot as well. What are the failures you >>> see? >>> >>> >>> >>>> >>> >>>> >>> >>>> Thanks, >>> >>>> Greg >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Wed, May 22, 2013 at 9:39 PM, Alexey Samsonov < >>> samsonov at google.com> >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi! >>> >>>>> >>> >>>>> The docs look strange to me - I don't indeed see any CMake support >>> for >>> >>>>> running compiler-rt tests. >>> >>>>> Probably compiler-rt folks can comment on this... >>> >>>>> I think you should run compilert-rt tests manually by smth. like >>> >>>>> compiler-rt/test/Unit/test. >>> >>>>> >>> >>>>> CMake build system is able of running a bunch of sanitizer tests >>> >>>>> (AddressSanitizer, ThreadSanitizer etc.), and it assumes that >>> >>>>> compiler-rt is checked out to llvm/projects/compiler-rt. >>> Apparently, >>> >>>>> this is a problem. There was a patch that tried to address this, >>> but >>> >>>>> it never got committed. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Wed, May 22, 2013 at 11:38 PM, Greg Fitzgerald < >>> garious at gmail.com> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Anybody working on porting the compiler-rt tests to cmake? >>> >>>>>> >>> >>>>>> The online documentation shows a preference for cmake and ctest, >>> but >>> >>>>>> the CMakeLists file has the comment "Currently the tests have not >>> been >>> >>>>>> ported to CMake, so disable this directory." How should we be >>> running the >>> >>>>>> test suite? >>> >>>>>> >>> >>>>>> http://compiler-rt.llvm.org/ >>> >>>>>> >>> >>>>>> My immediate issue is that "make check-all" fails in the cmake >>> build >>> >>>>>> when compiler-rt is outside the projects directory. When I point >>> to >>> >>>>>> compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still >>> looks for >>> >>>>>> lit.common.cfg within "projects/compiler-rt" instead of the >>> external >>> >>>>>> directory. I use similar CMake variables for Clang and Polly and >>> have had >>> >>>>>> no trouble. Any recommendations for how to fix? >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> Greg >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> 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 >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Alexey Samsonov, MSK >>> >> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> > >>> _______________________________________________ >>> 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/20130528/5e26c6e9/attachment.html>
Sure, r182831. On Wed, May 29, 2013 at 6:38 AM, Greg Fitzgerald <garious at gmail.com> wrote:>> Android runtime is special, we build it in a separate build tree >> configured with >> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake > > This worked great, thanks! Would you mind tweaking Android.cmake so that I > can override the location of the C compiler? The current version forces me > to use the just-built-clang and that the new build directory be in a sibling > directory. But as you mentioned, we can build compiler-rt with a any recent > version of gcc or clang. Here's the change I'm looking for: > > > diff --git a/cmake/platforms/Android.cmake b/cmake/platforms/Android.cmake > index 72849b1..5f732ce 100644 > --- a/cmake/platforms/Android.cmake > +++ b/cmake/platforms/Android.cmake > @@ -11,8 +11,15 @@ > # make <target> > > SET(CMAKE_SYSTEM_NAME Linux) > + > +IF(NOT CMAKE_C_COMPILER) > SET(CMAKE_C_COMPILER ${CMAKE_BINARY_DIR}/../bin/clang) > +ENDIF() > + > +IF(NOT CMAKE_CXX_COMPILER) > SET(CMAKE_CXX_COMPILER ${CMAKE_BINARY_DIR}/../bin/clang++) > +ENDIF() > + > SET(ANDROID "1" CACHE STRING "ANDROID" FORCE) > > SET(ANDROID_COMMON_FLAGS "-target arm-linux-androideabi > --sysroot=${LLVM_ANDROID_TOOLCHAIN_DIR}/sysroot > -B${LLVM_ANDROID_TOOLCHAIN_DIR} -mllvm -arm-enable-ehabi") > > > > > On Tue, May 28, 2013 at 11:26 AM, Greg Fitzgerald <garious at gmail.com> wrote: >> >> Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang >> 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like >> everything works great, but that you just need to make those UB tests >> 'unsupported' since they fail with "libclang_rt.ubsan was built without >> __int128 support". >> >> Thanks, >> Greg >> >> >> >> On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov <samsonov at google.com> >> wrote: >>> >>> >>> On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov >>> <eugeni.stepanov at gmail.com> wrote: >>>> >>>> On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> >>>> wrote: >>>> > When I build compiler-rt with clang 3.2, all lsan tests pass. The >>>> > only >>>> > failing tests I see are in ubsan: >>>> > >>>> > Failing Tests (6): >>>> > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/div-zero.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/uadd-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/usub-overflow.cpp >>>> > >>>> > >>>> > When I build with gcc 4.4.3, I need the changes below to get the >>>> > source to >>>> > compile (and then the lsan tests fails). What are you all using to >>>> > build >>>> > compiler-rt? are you developing on linux, osx or windows? Using gcc >>>> > or >>>> > llvm? Which should I expect to work? Any buildbots running? >>>> >>> >>> As Evgeniy said, we build compiler-rt on Linux and on Mac OS X, and run >>> tests for various sanitizers on our buildbots. >>> Note that CMake build system of compiler-rt uses host compiler to build >>> it. On Linux we use: >>> 1) gcc 4.6.3 >>> 2) tip-of-the-trunk Clang, >>> and tests pass under both of these. >>> >>> gcc 4.4.3 seems way too old, so in some sense we've dropped support for >>> it (you have to make changes, as old gcc is not >>> smart enough to make some POD variables thread-local). >>> >>>> >>>> I think we build compiler-rt with the host compiler, except for >>>> Android. Which is usually a recently-built clang. n Linux, but we >>>> exercise osx build on our buildbots. >>>> We never build with compiler-rt not in projects/. >>>> Our bot scripts are here: >>>> >>>> https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave >>>> The bots itself are not publicly visible, we hope to change that soon. >>>> >>>> > >>>> > And lastly, are there build instructions to build the Android shared >>>> > object? >>>> > Is there any way to build an android static lib? How about for >>>> > arm-linux? >>>> >>>> Android runtime is special, we build it in a separate build tree >>>> configured with >>>> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake >>>> See buildbot_cmake.sh for details. >>>> >>>> > >>>> > Thanks, >>>> > Greg >>>> > >>>> > >>>> > diff --git a/lib/interception/interception.h >>>> > b/lib/interception/interception.h >>>> > index d50af35..1771d4e 100644 >>>> > --- a/lib/interception/interception.h >>>> > +++ b/lib/interception/interception.h >>>> > @@ -27,8 +27,8 @@ typedef __sanitizer::uptr SIZE_T; >>>> > typedef __sanitizer::sptr SSIZE_T; >>>> > typedef __sanitizer::sptr PTRDIFF_T; >>>> > typedef __sanitizer::s64 INTMAX_T; >>>> > -typedef __sanitizer::OFF_T OFF_T; >>>> > -typedef __sanitizer::OFF64_T OFF64_T; >>>> > +//typedef __sanitizer::OFF_T OFF_T; >>>> > +//typedef __sanitizer::OFF64_T OFF64_T; >>>> > >>>> > // How to add an interceptor: >>>> > // Suppose you need to wrap/replace system function (generally, from >>>> > libc): >>>> > diff --git a/lib/lsan/lsan_allocator.cc b/lib/lsan/lsan_allocator.cc >>>> > index 9bf27b1..190dce8 100644 >>>> > --- a/lib/lsan/lsan_allocator.cc >>>> > +++ b/lib/lsan/lsan_allocator.cc >>>> > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, >>>> > AllocatorCache, >>>> > SecondaryAllocator> Allocator; >>>> > >>>> > static Allocator allocator; >>>> > -static THREADLOCAL AllocatorCache cache; >>>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>>> > >>>> > void InitializeAllocator() { >>>> > allocator.Init(); >>>> > diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc >>>> > index 7435843..3e6adb6 100644 >>>> > --- a/lib/msan/msan_allocator.cc >>>> > +++ b/lib/msan/msan_allocator.cc >>>> > @@ -33,7 +33,7 @@ typedef LargeMmapAllocator<> SecondaryAllocator; >>>> > typedef CombinedAllocator<PrimaryAllocator, AllocatorCache, >>>> > SecondaryAllocator> Allocator; >>>> > >>>> > -static THREADLOCAL AllocatorCache cache; >>>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>>> > static Allocator allocator; >>>> > >>>> > static int inited = 0; >>>> > >>>> > >>>> > >>>> > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> >>>> > wrote: >>>> >> >>>> >> I blame this line in lsan/lit_tests/lit.cfg: >>>> >> >>>> >> # Setup attributes common for all compiler-rt projects. >>>> >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", >>>> >> "compiler-rt", >>>> >> "lib", "lit.common.cfg") >>>> >> >>>> >> >>>> >> On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov >>>> >> <samsonov at google.com> >>>> >> wrote: >>>> >>> >>>> >>> >>>> >>> On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald <garious at gmail.com> >>>> >>> wrote: >>>> >>>> >>>> >>>> > it assumes that compiler-rt is checked out to >>>> >>>> > llvm/projects/compiler-rt. Apparently, this is a problem. >>>> >>>> >>>> >>>> I have a patch for this ready. I'll send it to you and >>>> >>>> llvm-commits. >>>> >>>> Most of the tests pass with "make check-all" but the recently-added >>>> >>>> lsan >>>> >>>> tests are all failing. Do those fail for you as well? If so, can >>>> >>>> we XFAIL >>>> >>>> them for now and try to keep the "make check-all" build clean? >>>> >>> >>>> >>> >>>> >>> Thanks! I'll take a look at the patch today. LSan tests work fine >>>> >>> for me, >>>> >>> and we have them on our buildbot as well. What are the failures you >>>> >>> see? >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Greg >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, May 22, 2013 at 9:39 PM, Alexey Samsonov >>>> >>>> <samsonov at google.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi! >>>> >>>>> >>>> >>>>> The docs look strange to me - I don't indeed see any CMake support >>>> >>>>> for >>>> >>>>> running compiler-rt tests. >>>> >>>>> Probably compiler-rt folks can comment on this... >>>> >>>>> I think you should run compilert-rt tests manually by smth. like >>>> >>>>> compiler-rt/test/Unit/test. >>>> >>>>> >>>> >>>>> CMake build system is able of running a bunch of sanitizer tests >>>> >>>>> (AddressSanitizer, ThreadSanitizer etc.), and it assumes that >>>> >>>>> compiler-rt is checked out to llvm/projects/compiler-rt. >>>> >>>>> Apparently, >>>> >>>>> this is a problem. There was a patch that tried to address this, >>>> >>>>> but >>>> >>>>> it never got committed. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Wed, May 22, 2013 at 11:38 PM, Greg Fitzgerald >>>> >>>>> <garious at gmail.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Anybody working on porting the compiler-rt tests to cmake? >>>> >>>>>> >>>> >>>>>> The online documentation shows a preference for cmake and ctest, >>>> >>>>>> but >>>> >>>>>> the CMakeLists file has the comment "Currently the tests have not >>>> >>>>>> been >>>> >>>>>> ported to CMake, so disable this directory." How should we be >>>> >>>>>> running the >>>> >>>>>> test suite? >>>> >>>>>> >>>> >>>>>> http://compiler-rt.llvm.org/ >>>> >>>>>> >>>> >>>>>> My immediate issue is that "make check-all" fails in the cmake >>>> >>>>>> build >>>> >>>>>> when compiler-rt is outside the projects directory. When I point >>>> >>>>>> to >>>> >>>>>> compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still >>>> >>>>>> looks for >>>> >>>>>> lit.common.cfg within "projects/compiler-rt" instead of the >>>> >>>>>> external >>>> >>>>>> directory. I use similar CMake variables for Clang and Polly and >>>> >>>>>> have had >>>> >>>>>> no trouble. Any recommendations for how to fix? >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> Greg >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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 >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Alexey Samsonov, MSK >>>> >> >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> > >>>> _______________________________________________ >>>> 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 >> >> >
UBsan tests work for me when I run "check-ubsan" in both build trees (the one with gcc 4.6.3 as a host compiler, and the one with fresh Clang). It's pretty convenient for us to use fresh Clang to configure LLVM and compiler-rt. One major reason is that autoconf/make build system always builds compiler-rt with just-built Clang. There are other benefits, like keeping sanitizers code "-Werror"-clean under the fresh Clang, ability to catch regressions in compiler etc. Why would you need a fixed version? On Tue, May 28, 2013 at 10:26 PM, Greg Fitzgerald <garious at gmail.com> wrote:> Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang > 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks > like everything works great, but that you just need to make those UB tests > 'unsupported' since they fail with "libclang_rt.ubsan was built without > __int128 support". > > Thanks, > Greg > > > > On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov <samsonov at google.com>wrote: > >> >> On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov < >> eugeni.stepanov at gmail.com> wrote: >> >>> On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> >>> wrote: >>> > When I build compiler-rt with clang 3.2, all lsan tests pass. The only >>> > failing tests I see are in ubsan: >>> > >>> > Failing Tests (6): >>> > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/div-zero.cpp >>> > UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/uadd-overflow.cpp >>> > UndefinedBehaviorSanitizer :: Integer/usub-overflow.cpp >>> > >>> > >>> > When I build with gcc 4.4.3, I need the changes below to get the >>> source to >>> > compile (and then the lsan tests fails). What are you all using to >>> build >>> > compiler-rt? are you developing on linux, osx or windows? Using gcc >>> or >>> > llvm? Which should I expect to work? Any buildbots running? >>> >>> >> As Evgeniy said, we build compiler-rt on Linux and on Mac OS X, and run >> tests for various sanitizers on our buildbots. >> Note that CMake build system of compiler-rt uses host compiler to build >> it. On Linux we use: >> 1) gcc 4.6.3 >> 2) tip-of-the-trunk Clang, >> and tests pass under both of these. >> >> gcc 4.4.3 seems way too old, so in some sense we've dropped support for >> it (you have to make changes, as old gcc is not >> smart enough to make some POD variables thread-local). >> >> >>> I think we build compiler-rt with the host compiler, except for >>> Android. Which is usually a recently-built clang. n Linux, but we >>> exercise osx build on our buildbots. >>> We never build with compiler-rt not in projects/. >>> Our bot scripts are here: >>> >>> https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave >>> The bots itself are not publicly visible, we hope to change that soon. >>> >>> > >>> > And lastly, are there build instructions to build the Android shared >>> object? >>> > Is there any way to build an android static lib? How about for >>> arm-linux? >>> >>> Android runtime is special, we build it in a separate build tree >>> configured with >>> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake >>> See buildbot_cmake.sh for details. >>> >>> > >>> > Thanks, >>> > Greg >>> > >>> > >>> > diff --git a/lib/interception/interception.h >>> > b/lib/interception/interception.h >>> > index d50af35..1771d4e 100644 >>> > --- a/lib/interception/interception.h >>> > +++ b/lib/interception/interception.h >>> > @@ -27,8 +27,8 @@ typedef __sanitizer::uptr SIZE_T; >>> > typedef __sanitizer::sptr SSIZE_T; >>> > typedef __sanitizer::sptr PTRDIFF_T; >>> > typedef __sanitizer::s64 INTMAX_T; >>> > -typedef __sanitizer::OFF_T OFF_T; >>> > -typedef __sanitizer::OFF64_T OFF64_T; >>> > +//typedef __sanitizer::OFF_T OFF_T; >>> > +//typedef __sanitizer::OFF64_T OFF64_T; >>> > >>> > // How to add an interceptor: >>> > // Suppose you need to wrap/replace system function (generally, from >>> libc): >>> > diff --git a/lib/lsan/lsan_allocator.cc b/lib/lsan/lsan_allocator.cc >>> > index 9bf27b1..190dce8 100644 >>> > --- a/lib/lsan/lsan_allocator.cc >>> > +++ b/lib/lsan/lsan_allocator.cc >>> > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, >>> > AllocatorCache, >>> > SecondaryAllocator> Allocator; >>> > >>> > static Allocator allocator; >>> > -static THREADLOCAL AllocatorCache cache; >>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>> > >>> > void InitializeAllocator() { >>> > allocator.Init(); >>> > diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc >>> > index 7435843..3e6adb6 100644 >>> > --- a/lib/msan/msan_allocator.cc >>> > +++ b/lib/msan/msan_allocator.cc >>> > @@ -33,7 +33,7 @@ typedef LargeMmapAllocator<> SecondaryAllocator; >>> > typedef CombinedAllocator<PrimaryAllocator, AllocatorCache, >>> > SecondaryAllocator> Allocator; >>> > >>> > -static THREADLOCAL AllocatorCache cache; >>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>> > static Allocator allocator; >>> > >>> > static int inited = 0; >>> > >>> > >>> > >>> > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> >>> wrote: >>> >> >>> >> I blame this line in lsan/lit_tests/lit.cfg: >>> >> >>> >> # Setup attributes common for all compiler-rt projects. >>> >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", >>> >> "compiler-rt", >>> >> "lib", "lit.common.cfg") >>> >> >>> >> >>> >> On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com >>> > >>> >> wrote: >>> >>> >>> >>> >>> >>> On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald <garious at gmail.com> >>> >>> wrote: >>> >>>> >>> >>>> > it assumes that compiler-rt is checked out to >>> >>>> > llvm/projects/compiler-rt. Apparently, this is a problem. >>> >>>> >>> >>>> I have a patch for this ready. I'll send it to you and >>> llvm-commits. >>> >>>> Most of the tests pass with "make check-all" but the recently-added >>> lsan >>> >>>> tests are all failing. Do those fail for you as well? If so, can >>> we XFAIL >>> >>>> them for now and try to keep the "make check-all" build clean? >>> >>> >>> >>> >>> >>> Thanks! I'll take a look at the patch today. LSan tests work fine >>> for me, >>> >>> and we have them on our buildbot as well. What are the failures you >>> see? >>> >>> >>> >>>> >>> >>>> >>> >>>> Thanks, >>> >>>> Greg >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Wed, May 22, 2013 at 9:39 PM, Alexey Samsonov < >>> samsonov at google.com> >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi! >>> >>>>> >>> >>>>> The docs look strange to me - I don't indeed see any CMake support >>> for >>> >>>>> running compiler-rt tests. >>> >>>>> Probably compiler-rt folks can comment on this... >>> >>>>> I think you should run compilert-rt tests manually by smth. like >>> >>>>> compiler-rt/test/Unit/test. >>> >>>>> >>> >>>>> CMake build system is able of running a bunch of sanitizer tests >>> >>>>> (AddressSanitizer, ThreadSanitizer etc.), and it assumes that >>> >>>>> compiler-rt is checked out to llvm/projects/compiler-rt. >>> Apparently, >>> >>>>> this is a problem. There was a patch that tried to address this, >>> but >>> >>>>> it never got committed. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Wed, May 22, 2013 at 11:38 PM, Greg Fitzgerald < >>> garious at gmail.com> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Anybody working on porting the compiler-rt tests to cmake? >>> >>>>>> >>> >>>>>> The online documentation shows a preference for cmake and ctest, >>> but >>> >>>>>> the CMakeLists file has the comment "Currently the tests have not >>> been >>> >>>>>> ported to CMake, so disable this directory." How should we be >>> running the >>> >>>>>> test suite? >>> >>>>>> >>> >>>>>> http://compiler-rt.llvm.org/ >>> >>>>>> >>> >>>>>> My immediate issue is that "make check-all" fails in the cmake >>> build >>> >>>>>> when compiler-rt is outside the projects directory. When I point >>> to >>> >>>>>> compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still >>> looks for >>> >>>>>> lit.common.cfg within "projects/compiler-rt" instead of the >>> external >>> >>>>>> directory. I use similar CMake variables for Clang and Polly and >>> have had >>> >>>>>> no trouble. Any recommendations for how to fix? >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> Greg >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> 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 >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Alexey Samsonov, MSK >>> >> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> > >>> _______________________________________________ >>> 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 >> > >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130529/f445ab65/attachment.html>
For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote:> UBsan tests work for me when I run "check-ubsan" in both build trees (the one with gcc 4.6.3 as a host compiler, and the one with fresh Clang). > It's pretty convenient for us to use fresh Clang to configure LLVM and compiler-rt. One major reason is that autoconf/make build system always builds compiler-rt with just-built Clang. > There are other benefits, like keeping sanitizers code "-Werror"-clean under the fresh Clang, ability to catch regressions in compiler etc. Why would you need a fixed version? > > > On Tue, May 28, 2013 at 10:26 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". >> >> Thanks, >> Greg >> >> >> >> On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov <samsonov at google.com> wrote: >>> >>> On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: >>>> On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> wrote: >>>> > When I build compiler-rt with clang 3.2, all lsan tests pass. The only >>>> > failing tests I see are in ubsan: >>>> > >>>> > Failing Tests (6): >>>> > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/div-zero.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/uadd-overflow.cpp >>>> > UndefinedBehaviorSanitizer :: Integer/usub-overflow.cpp >>>> > >>>> > >>>> > When I build with gcc 4.4.3, I need the changes below to get the source to >>>> > compile (and then the lsan tests fails). What are you all using to build >>>> > compiler-rt? are you developing on linux, osx or windows? Using gcc or >>>> > llvm? Which should I expect to work? Any buildbots running? >>> >>> As Evgeniy said, we build compiler-rt on Linux and on Mac OS X, and run tests for various sanitizers on our buildbots. >>> Note that CMake build system of compiler-rt uses host compiler to build it. On Linux we use: >>> 1) gcc 4.6.3 >>> 2) tip-of-the-trunk Clang, >>> and tests pass under both of these. >>> >>> gcc 4.4.3 seems way too old, so in some sense we've dropped support for it (you have to make changes, as old gcc is not >>> smart enough to make some POD variables thread-local). >>> >>>> I think we build compiler-rt with the host compiler, except for >>>> Android. Which is usually a recently-built clang. n Linux, but we >>>> exercise osx build on our buildbots. >>>> We never build with compiler-rt not in projects/. >>>> Our bot scripts are here: >>>> https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave >>>> The bots itself are not publicly visible, we hope to change that soon. >>>> >>>> > >>>> > And lastly, are there build instructions to build the Android shared object? >>>> > Is there any way to build an android static lib? How about for arm-linux? >>>> >>>> Android runtime is special, we build it in a separate build tree configured with >>>> -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake >>>> See buildbot_cmake.sh for details. >>>> >>>> > >>>> > Thanks, >>>> > Greg >>>> > >>>> > >>>> > diff --git a/lib/interception/interception.h >>>> > b/lib/interception/interception.h >>>> > index d50af35..1771d4e 100644 >>>> > --- a/lib/interception/interception.h >>>> > +++ b/lib/interception/interception.h >>>> > @@ -27,8 +27,8 @@ typedef __sanitizer::uptr SIZE_T; >>>> > typedef __sanitizer::sptr SSIZE_T; >>>> > typedef __sanitizer::sptr PTRDIFF_T; >>>> > typedef __sanitizer::s64 INTMAX_T; >>>> > -typedef __sanitizer::OFF_T OFF_T; >>>> > -typedef __sanitizer::OFF64_T OFF64_T; >>>> > +//typedef __sanitizer::OFF_T OFF_T; >>>> > +//typedef __sanitizer::OFF64_T OFF64_T; >>>> > >>>> > // How to add an interceptor: >>>> > // Suppose you need to wrap/replace system function (generally, from libc): >>>> > diff --git a/lib/lsan/lsan_allocator.cc b/lib/lsan/lsan_allocator.cc >>>> > index 9bf27b1..190dce8 100644 >>>> > --- a/lib/lsan/lsan_allocator.cc >>>> > +++ b/lib/lsan/lsan_allocator.cc >>>> > @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator, >>>> > AllocatorCache, >>>> > SecondaryAllocator> Allocator; >>>> > >>>> > static Allocator allocator; >>>> > -static THREADLOCAL AllocatorCache cache; >>>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>>> > >>>> > void InitializeAllocator() { >>>> > allocator.Init(); >>>> > diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc >>>> > index 7435843..3e6adb6 100644 >>>> > --- a/lib/msan/msan_allocator.cc >>>> > +++ b/lib/msan/msan_allocator.cc >>>> > @@ -33,7 +33,7 @@ typedef LargeMmapAllocator<> SecondaryAllocator; >>>> > typedef CombinedAllocator<PrimaryAllocator, AllocatorCache, >>>> > SecondaryAllocator> Allocator; >>>> > >>>> > -static THREADLOCAL AllocatorCache cache; >>>> > +static /*THREADLOCAL*/ AllocatorCache cache; >>>> > static Allocator allocator; >>>> > >>>> > static int inited = 0; >>>> > >>>> > >>>> > >>>> > On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <earthdok at google.com> wrote: >>>> >> >>>> >> I blame this line in lsan/lit_tests/lit.cfg: >>>> >> >>>> >> # Setup attributes common for all compiler-rt projects. >>>> >> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects", >>>> >> "compiler-rt", >>>> >> "lib", "lit.common.cfg") >>>> >> >>>> >> >>>> >> On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <samsonov at google.com> >>>> >> wrote: >>>> >>> >>>> >>> >>>> >>> On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald <garious at gmail.com> >>>> >>> wrote: >>>> >>>> >>>> >>>> > it assumes that compiler-rt is checked out to >>>> >>>> > llvm/projects/compiler-rt. Apparently, this is a problem. >>>> >>>> >>>> >>>> I have a patch for this ready. I'll send it to you and llvm-commits. >>>> >>>> Most of the tests pass with "make check-all" but the recently-added lsan >>>> >>>> tests are all failing. Do those fail for you as well? If so, can we XFAIL >>>> >>>> them for now and try to keep the "make check-all" build clean? >>>> >>> >>>> >>> >>>> >>> Thanks! I'll take a look at the patch today. LSan tests work fine for me, >>>> >>> and we have them on our buildbot as well. What are the failures you see? >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Greg >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, May 22, 2013 at 9:39 PM, Alexey Samsonov <samsonov at google.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Hi! >>>> >>>>> >>>> >>>>> The docs look strange to me - I don't indeed see any CMake support for >>>> >>>>> running compiler-rt tests. >>>> >>>>> Probably compiler-rt folks can comment on this... >>>> >>>>> I think you should run compilert-rt tests manually by smth. like >>>> >>>>> compiler-rt/test/Unit/test. >>>> >>>>> >>>> >>>>> CMake build system is able of running a bunch of sanitizer tests >>>> >>>>> (AddressSanitizer, ThreadSanitizer etc.), and it assumes that >>>> >>>>> compiler-rt is checked out to llvm/projects/compiler-rt. Apparently, >>>> >>>>> this is a problem. There was a patch that tried to address this, but >>>> >>>>> it never got committed. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Wed, May 22, 2013 at 11:38 PM, Greg Fitzgerald <garious at gmail.com> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> Anybody working on porting the compiler-rt tests to cmake? >>>> >>>>>> >>>> >>>>>> The online documentation shows a preference for cmake and ctest, but >>>> >>>>>> the CMakeLists file has the comment "Currently the tests have not been >>>> >>>>>> ported to CMake, so disable this directory." How should we be running the >>>> >>>>>> test suite? >>>> >>>>>> >>>> >>>>>> http://compiler-rt.llvm.org/ >>>> >>>>>> >>>> >>>>>> My immediate issue is that "make check-all" fails in the cmake build >>>> >>>>>> when compiler-rt is outside the projects directory. When I point to >>>> >>>>>> compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still looks for >>>> >>>>>> lit.common.cfg within "projects/compiler-rt" instead of the external >>>> >>>>>> directory. I use similar CMake variables for Clang and Polly and have had >>>> >>>>>> no trouble. Any recommendations for how to fix? >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> Greg >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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 >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Alexey Samsonov, MSK >>>> >> >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> > >>>> _______________________________________________ >>>> 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 > > > > -- > Alexey Samsonov, MSK-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130529/616b2c88/attachment.html>