<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 9:23 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div><font><span style="background-color:rgba(255,255,255,0)">> I don't think it's a good idea to let user hijack </span></font></div>
<div><font><span style="background-color:rgba(255,255,255,0)">> the driver and stuff in custom version of</span></font></div>
<div><font><span style="background-color:rgba(255,255,255,0)">> </span></font><span style="background-color:rgba(255,255,255,0);font-size:small">ASan runtime instead the one installed/built </span></div><div><span style="background-color:rgba(255,255,255,0);font-size:small">> with compiler :)</span></div>
<div><span style="background-color:rgba(255,255,255,0);font-size:small"><br></span></div></div><div><font><span>I'm okay with it. This is open source. If someone wants to put the sanitizers on a shorter release cycle than the full toolchain, who are we to hold them back?</span></font></div>
</blockquote><div><br></div><div>They can always rebuild the fresh ASan from source and replace the ASan runtime in toolchain with the new one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<div><span style="background-color:rgba(255,255,255,0);font-size:small"><br></span></div><div><font><span style="background-color:rgba(255,255,255,0)">> What do you mean by "invoking the test-suite directly"?</span></font><span style="background-color:rgba(255,255,255,0);font-size:small"><br>
</span></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div></div><div><font><span>In Clang's CMakeLists, add_subdirectory() of compiler-rt's 'test' directory. I suggested we do this earlier, because of clang's hardcoded dependency on the path to ASan. Instead, I think a better solution is to break the hardcoded dependency, allowing the test suite to<span></span> point clang to compiler-rt's local copy of ASan using a '-L' parameter.</span></font></div>
</blockquote><div><br></div><div>I don't believe it's needed anywhere except in the testing infrastructure you suggest. And, again, we have to ensure that -L/path/to/new/asan provided by user "wins" over -L/path/to/clang/resource/dir, and we have strong reasons to put the latter as early in the link line as possible. That said, ....</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><font><span><br></span></font></div><div><font><span>Greg</span></font></div><div><div class="h5"><div><span style="background-color:rgba(255,255,255,0);font-size:small"><br></span></div><br>On Thursday, April 3, 2014, Alexey Samsonov <<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 5:04 AM, Greg Fitzgerald <span dir="ltr"><<a>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>> we would still want to use compiler-rt test-suite in a standalone mode, to test fully built/installed toolchains,<br>
and even GCC.<br>
<br>
</div>Sounds good.<br>
<div><br>
<br>
> Clang driver links the static xsan runtimes from a hardcoded<br>
> paths in Clang resource directory, and doesn't add flags like<br>
> "-lasan -L/path/to/clang/resource/dir". I find this behavior reasonable.<br>
<br>
</div>Can we change the flags to "-lasan -L/path/to/clang/resource/dir"? If<br>
we make that change,</blockquote><div><br></div><div>I don't think it's a good idea to let user hijack the driver and stuff in custom version of</div><div>ASan runtime instead the one installed/built with compiler :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I can stop suggesting that the clang build should<br>
invoke the compiler-rt test suite directly. :-)<br></blockquote><div><br></div><div>I haven't yet fully understood your complaints.</div></div></div></div></div></div></blockquote></blockquote><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div><div class="h5"><div class="gmail_quote"><div> Note that if you build/configure compiler-rt</div><div>in a standalone mode, then "make check-compiler-rt" in that tree wouldn't rebuild runtimes,</div>
<div>and instead assume that they are provided by toolchain (that is, in standalone mode runtimes and</div><div>test suites are effectively independent).</div></div></div></div></div></div></blockquote></blockquote><div>
<br></div><div>^^^^</div><div>What is wrong with that approach?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div><div class="h5"><div class="gmail_quote"><div> What do you mean by "invoking the test-suite directly"?</div>
<div> </div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
> Do you want to give it a try?<br>
<br>
</div>I'll take a crack it, sure.<br>
<br>
<br>
By the way, locally, I now have just over half the ASan test suite<br>
passing ARM-Linux via QEMU. It's been really convenient to build<br>
compiler-rt in standalone mode. The edit-compile-run cycle is much<br>
shorter this way. Thanks for your help in making this work!<br>
<span><font color="#888888"><br>
-Greg<br>
</font></span><div><div><br>
<br>
<br>
On Wed, Apr 2, 2014 at 7:56 AM, Alexey Samsonov <<a>samsonov@google.com</a>> wrote:<br>
> Hi Greg,<br>
><br>
> On Wed, Apr 2, 2014 at 2:50 AM, Greg Fitzgerald <<a>garious@gmail.com</a>> wrote:<br>
>><br>
>> Alexey, Evgeniy,<br>
>><br>
>> I propose the following steps to unify multi-arch support in compiler-rt:<br>
>><br>
>> 1) The compiler-rt test suite adds "-L${CMAKE_CURRENT_BINARY_DIR}/lib"<br>
>> to its 'clang' variables. This way we can test the sanitizers without<br>
>> installing any libs to the just-built-clang install directory.<br>
><br>
><br>
> This is possible, but please keep in mind that:<br>
> 1) we would still want to use compiler-rt test-suite in a standalone mode,<br>
> to test fully built/installed toolchains,<br>
> and even GCC.<br>
> 2) Adding -L... wouldn't work: Clang driver links the static xsan runtimes<br>
> from a hardcoded paths in Clang resource directory,<br>
> and doesn't add flags like "-lasan -L/path/to/clang/resource/dir". I find<br>
> this behavior reasonable.<br>
><br>
> I don't see a problem with the current approach - we can make "run sanitizer<br>
> test suite" command in the<br>
> top-level build tree depend on "build/install compiler-rt ExternalProject"<br>
> steps (see how it's done currently).<br>
><br>
>><br>
>><br>
>> 2) The "clang/runtime" build calls ExternalProject once for each arch<br>
>> it needs of compiler-rt. So once to create x86_64 libs and once for<br>
>> i386 libs.<br>
>><br>
>> 3) The compiler-rt build drops the ${arch} suffix from its libs, and<br>
>> the "clang/runtime" build uses CMAKE_INSTALL_PREFIX to control where<br>
>> the compiler-rt libs go.<br>
>><br>
>> "CMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/lib/clang/${CLANG_VERSION}/x86_64-linux"<br>
>><br>
>><br>
>> 4) Remove multi-arch support from the compiler-rt build. Instead,<br>
>> declare compiler-rt as an "any-arch" build, configured with:<br>
>> CMAKE_CXX_COMPILER (defaults to just-built-clang)<br>
>> CMAKE_CXX_FLAGS (defaults to llvm's default target)<br>
>> COMPILER_RT_TEST_COMPILER (defaults to CMAKE_CXX_COMPILER)<br>
>> COMPILER_RT_TEST_FLAGS (defaults to CMAKE_CXX_FLAGS)<br>
><br>
><br>
> Unfortunately, this could be problematic for Mac - we use "universal<br>
> binaries" there - a single static/dynamic runtime<br>
> which contains runtimes for all the possible architectures. We might work<br>
> around this, however, by adding a custom<br>
> Mac-specific step that would merge all single-arch binaries into a<br>
> multi-arch one - I think this is fine as long as we<br>
> greatly simplify the rest of the ugly build system.<br>
><br>
> Do you want to give it a try?<br>
><br>
>><br>
>><br>
>> Thoughts?<br>
>><br>
>> Thanks,<br>
>> Greg<br>
>><br>
>> On Tue, Apr 1, 2014 at 12:58 AM, Evgeniy Stepanov<br>
>> <<a>eugeni.stepanov@gmail.com</a>> wrote:<br>
>> > It does sound like Android is better suited for "honest"<br>
>> > cross-compilation, rather than "build compiler-rt for all targets we<br>
>> > can find" model.<br>
>> ><br>
>> > I'm still not convinced that we must require the "ninja install" step.<br>
>> > Could we just "ninja clang" and then build the second stage against<br>
>> > the first stage build directory? Will this "find_package" thing not<br>
>> > work that way, or do you mean it as a way to copy target asan runtime<br>
>> > where the first stage compiler will find it (or probably both)?<br>
>> ><br>
>> > On Mon, Mar 31, 2014 at 6:46 PM, Alexey Samsonov <<a>samsonov@google.com</a>><br>
>> > wrote:<br>
></div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Alexey Samsonov, MSK</div>
</font></span></div></div>
</blockquote>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>