[LLVMdev] compiler-rt tests in cmake?
Greg Fitzgerald
garious at gmail.com
Tue May 28 19:38:01 PDT 2013
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130528/5e26c6e9/attachment.html>
More information about the llvm-dev
mailing list