<div dir="ltr">+eugenis@, our Android expert. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <span dir="ltr"><<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im"><div>> Cool, can you use clang 3.3 then? :)<br></div><div><br></div></div><div>I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc 4.6.3.</div>
<div><br></div><div><br></div><div>Back to Android, I built the ASan shared object and successfully ran this example:</div><div><a href="https://code.google.com/p/address-sanitizer/source/browse/wiki/example_UseAfterFree.cc?r=1580" target="_blank">https://code.google.com/p/address-sanitizer/source/browse/wiki/example_UseAfterFree.cc?r=1580</a><br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">But unlike these instructions:</div><div class="gmail_extra"><a href="http://www.chromium.org/developers/testing/addresssanitizer" target="_blank">http://www.chromium.org/developers/testing/addresssanitizer</a><br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">the Android instructions don't mention asan_symbolize.py</div><div class="gmail_extra"><div class="gmail_extra"><a href="https://code.google.com/p/address-sanitizer/wiki/Android" target="_blank">https://code.google.com/p/address-sanitizer/wiki/Android</a><br>
</div><div><br></div><div>When I use asan_symbolize.py (from Linux), I see no symbols in the stack trace and the following error messages:</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">
<div class="gmail_extra">addr2line: '/data/example_UseAfterFree': No such file</div><div class="gmail_extra">addr2line: '/data/<a href="http://libclang_rt.asan-arm-android.so" target="_blank">libclang_rt.asan-arm-android.so</a>': No such file</div>
<div class="gmail_extra">addr2line: '/system/lib/libstdc++.so': No such file</div><div class="gmail_extra"><br></div><div class="gmail_extra">How can I decode those addresses in the stack trace? Is there a way to configure asan_symbolize.py to find my binaries and arm-linux-androideabi-addr2line?<br>
</div><div><br></div><div>Thanks,</div><div>Greg</div><div><br></div><div>P.S. Thanks for the colorful output. You make address sanitizing feel like Christmas.</div><div><br></div></div><div><div class="h5">
<div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 29, 2013 at 7:28 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>On Wed, May 29, 2013 at 5:40 PM, Greg Fitzgerald <span dir="ltr"><<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>For me, UBsan fails with clang 3.2 and passes with clang 3.3.</div>
</div></blockquote><div><br></div>
</div><div>Cool, can you use clang 3.3 then? :) I think that the reason selected UBSan tests fail under clang 3.2 is a bug in Clang, which was fixed (Richard may correct me if I'm wrong).<br></div><div>I don't really want to mark these tests as "failing on a certain version of host compiler".</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div><br></div><div>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.</div>
</div></blockquote><div><br></div></div><div>I think you may fix a host compiler (it may be clang 3.3 or gcc 4.6.3), build w/o -Werror and stay happy most of the time.</div><div>Bootstrap process (use system compiler to build Clang, use this Clang to build LLVM+Clang+compiler-rt) isn't really scary, it adds just a few lines to your build script.</div>
<div>AFAIK some developers actually do this every day. But, yes, this is not user-friendly, and we probably should document it better (or even provide the scripts) somewhere...</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto"><span><font color="#888888"><div><br></div><div>Greg</div></font></span><div><div><div><br></div><div><br>On May 29, 2013, at 12:30 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div><div dir="ltr">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).<div>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.</div>
<div>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?</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, May 28, 2013 at 10:26 PM, Greg Fitzgerald <span dir="ltr"><<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">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".<div>
<br></div><div>Thanks,</div><div>Greg</div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">
<div>On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>> wrote:<br>
> When I build compiler-rt with clang 3.2, all lsan tests pass. The only<br>
> failing tests I see are in ubsan:<br>
><br>
> Failing Tests (6):<br>
> UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp<br>
> UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp<br>
> UndefinedBehaviorSanitizer :: Integer/div-zero.cpp<br>
> UndefinedBehaviorSanitizer :: Integer/sub-overflow.cpp<br>
> UndefinedBehaviorSanitizer :: Integer/uadd-overflow.cpp<br>
> UndefinedBehaviorSanitizer :: Integer/usub-overflow.cpp<br>
><br>
><br>
> When I build with gcc 4.4.3, I need the changes below to get the source to<br>
> compile (and then the lsan tests fails). What are you all using to build<br>
> compiler-rt? are you developing on linux, osx or windows? Using gcc or<br>
> llvm? Which should I expect to work? Any buildbots running?<br>
<br></div></blockquote><div><br></div></div><div>As Evgeniy said, we build compiler-rt on Linux and on Mac OS X, and run tests for various sanitizers on our buildbots.</div><div>Note that CMake build system of compiler-rt uses host compiler to build it. On Linux we use:</div>
<div>1) gcc 4.6.3</div><div>2) tip-of-the-trunk Clang,</div><div>and tests pass under both of these.</div><div><br></div><div>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</div>
<div>smart enough to make some POD variables thread-local).</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
</div>I think we build compiler-rt with the host compiler, except for<br>
Android. Which is usually a recently-built clang. n Linux, but we<br>
exercise osx build on our buildbots.<br>
We never build with compiler-rt not in projects/.<br>
Our bot scripts are here:<br>
<a href="https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave" target="_blank">https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fbuild%2Fscripts%2Fslave</a><br>
The bots itself are not publicly visible, we hope to change that soon.<br>
<div><br>
><br>
> And lastly, are there build instructions to build the Android shared object?<br>
> Is there any way to build an android static lib? How about for arm-linux?<br>
<br>
</div>Android runtime is special, we build it in a separate build tree configured with<br>
-DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake<br>
See buildbot_cmake.sh for details.<br>
<div><div><br>
><br>
> Thanks,<br>
> Greg<br>
><br>
><br>
> diff --git a/lib/interception/interception.h<br>
> b/lib/interception/interception.h<br>
> index d50af35..1771d4e 100644<br>
> --- a/lib/interception/interception.h<br>
> +++ b/lib/interception/interception.h<br>
> @@ -27,8 +27,8 @@ typedef __sanitizer::uptr SIZE_T;<br>
> typedef __sanitizer::sptr SSIZE_T;<br>
> typedef __sanitizer::sptr PTRDIFF_T;<br>
> typedef __sanitizer::s64 INTMAX_T;<br>
> -typedef __sanitizer::OFF_T OFF_T;<br>
> -typedef __sanitizer::OFF64_T OFF64_T;<br>
> +//typedef __sanitizer::OFF_T OFF_T;<br>
> +//typedef __sanitizer::OFF64_T OFF64_T;<br>
><br>
> // How to add an interceptor:<br>
> // Suppose you need to wrap/replace system function (generally, from libc):<br>
> diff --git a/lib/lsan/lsan_allocator.cc b/lib/lsan/lsan_allocator.cc<br>
> index 9bf27b1..190dce8 100644<br>
> --- a/lib/lsan/lsan_allocator.cc<br>
> +++ b/lib/lsan/lsan_allocator.cc<br>
> @@ -43,7 +43,7 @@ typedef CombinedAllocator<PrimaryAllocator,<br>
> AllocatorCache,<br>
> SecondaryAllocator> Allocator;<br>
><br>
> static Allocator allocator;<br>
> -static THREADLOCAL AllocatorCache cache;<br>
> +static /*THREADLOCAL*/ AllocatorCache cache;<br>
><br>
> void InitializeAllocator() {<br>
> allocator.Init();<br>
> diff --git a/lib/msan/msan_allocator.cc b/lib/msan/msan_allocator.cc<br>
> index 7435843..3e6adb6 100644<br>
> --- a/lib/msan/msan_allocator.cc<br>
> +++ b/lib/msan/msan_allocator.cc<br>
> @@ -33,7 +33,7 @@ typedef LargeMmapAllocator<> SecondaryAllocator;<br>
> typedef CombinedAllocator<PrimaryAllocator, AllocatorCache,<br>
> SecondaryAllocator> Allocator;<br>
><br>
> -static THREADLOCAL AllocatorCache cache;<br>
> +static /*THREADLOCAL*/ AllocatorCache cache;<br>
> static Allocator allocator;<br>
><br>
> static int inited = 0;<br>
><br>
><br>
><br>
> On Fri, May 24, 2013 at 6:10 AM, Sergey Matveev <<a href="mailto:earthdok@google.com" target="_blank">earthdok@google.com</a>> wrote:<br>
>><br>
>> I blame this line in lsan/lit_tests/lit.cfg:<br>
>><br>
>> # Setup attributes common for all compiler-rt projects.<br>
>> compiler_rt_lit_cfg = os.path.join(llvm_src_root, "projects",<br>
>> "compiler-rt",<br>
>> "lib", "lit.common.cfg")<br>
>><br>
>><br>
>> On Fri, May 24, 2013 at 2:53 PM, Alexey Samsonov <<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On Fri, May 24, 2013 at 3:37 AM, Greg Fitzgerald <<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> > it assumes that compiler-rt is checked out to<br>
>>>> > llvm/projects/compiler-rt. Apparently, this is a problem.<br>
>>>><br>
>>>> I have a patch for this ready. I'll send it to you and llvm-commits.<br>
>>>> Most of the tests pass with "make check-all" but the recently-added lsan<br>
>>>> tests are all failing. Do those fail for you as well? If so, can we XFAIL<br>
>>>> them for now and try to keep the "make check-all" build clean?<br>
>>><br>
>>><br>
>>> Thanks! I'll take a look at the patch today. LSan tests work fine for me,<br>
>>> and we have them on our buildbot as well. What are the failures you see?<br>
>>><br>
>>>><br>
>>>><br>
>>>> Thanks,<br>
>>>> Greg<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Wed, May 22, 2013 at 9:39 PM, Alexey Samsonov <<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi!<br>
>>>>><br>
>>>>> The docs look strange to me - I don't indeed see any CMake support for<br>
>>>>> running compiler-rt tests.<br>
>>>>> Probably compiler-rt folks can comment on this...<br>
>>>>> I think you should run compilert-rt tests manually by smth. like<br>
>>>>> compiler-rt/test/Unit/test.<br>
>>>>><br>
>>>>> CMake build system is able of running a bunch of sanitizer tests<br>
>>>>> (AddressSanitizer, ThreadSanitizer etc.), and it assumes that<br>
>>>>> compiler-rt is checked out to llvm/projects/compiler-rt. Apparently,<br>
>>>>> this is a problem. There was a patch that tried to address this, but<br>
>>>>> it never got committed.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Wed, May 22, 2013 at 11:38 PM, Greg Fitzgerald <<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> Anybody working on porting the compiler-rt tests to cmake?<br>
>>>>>><br>
>>>>>> The online documentation shows a preference for cmake and ctest, but<br>
>>>>>> the CMakeLists file has the comment "Currently the tests have not been<br>
>>>>>> ported to CMake, so disable this directory." How should we be running the<br>
>>>>>> test suite?<br>
>>>>>><br>
>>>>>> <a href="http://compiler-rt.llvm.org/" target="_blank">http://compiler-rt.llvm.org/</a><br>
>>>>>><br>
>>>>>> My immediate issue is that "make check-all" fails in the cmake build<br>
>>>>>> when compiler-rt is outside the projects directory. When I point to<br>
>>>>>> compiler-rt with LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, lit still looks for<br>
>>>>>> lit.common.cfg within "projects/compiler-rt" instead of the external<br>
>>>>>> directory. I use similar CMake variables for Clang and Polly and have had<br>
>>>>>> no trouble. Any recommendations for how to fix?<br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>> Greg<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> LLVM Developers mailing list<br>
>>>>>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Alexey Samsonov, MSK<br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Alexey Samsonov, MSK<br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</font></span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div>
</div></blockquote></div></div></div></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</font></span></div></div>
</blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>