<div dir="ltr"><div class="gmail_extra">Hi Greg,</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 2, 2014 at 2:50 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">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></blockquote><div><br></div><div>This is possible, but please keep in mind that:</div><div>1) we would still want to use compiler-rt test-suite in a standalone mode, to test fully built/installed toolchains,</div>
<div>and even GCC.</div><div>2) Adding -L... wouldn't work: Clang driver links the static xsan runtimes from a hardcoded paths in Clang resource directory,</div><div>and doesn't add flags like "-lasan -L/path/to/clang/resource/dir". I find this behavior reasonable.</div>
<div><br></div><div>I don't see a problem with the current approach - we can make "run sanitizer test suite" command in the</div><div>top-level build tree depend on "build/install compiler-rt ExternalProject" steps (see how it's done currently).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
"CMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/lib/clang/${CLANG_VERSION}/x86_64-linux"<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>Unfortunately, this could be problematic for Mac - we use "universal binaries" there - a single static/dynamic runtime</div>
<div>which contains runtimes for all the possible architectures. We might work around this, however, by adding a custom</div><div>Mac-specific step that would merge all single-arch binaries into a multi-arch one - I think this is fine as long as we</div>
<div>greatly simplify the rest of the ugly build system.</div><div><br></div><div>Do you want to give it a try?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thoughts?<br>
<br>
Thanks,<br>
Greg<br>
<br>
On Tue, Apr 1, 2014 at 12:58 AM, Evgeniy Stepanov<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:eugeni.stepanov@gmail.com">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 href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
>><br>
>> On Fri, Mar 28, 2014 at 10:56 PM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>> wrote:<br>
>>><br>
>>> > Note that ASan tests on Android require llvm-symbolizer binary.<br>
>>><br>
>>> That's a really good point. And I see that llvm-symbolizer can't just<br>
>>> be pulled into compiler-rt because it has dependencies on DebugInfo,<br>
>>> Object, and Support libraries.<br>
>>><br>
>>><br>
>>> This throws a big wrench in Alexey's plan to have the native<br>
>>> compiler-rt build generate the cross-compiled binaries for all<br>
>>> supported targets. We would need to do the same in the llvm repo.<br>
>>> The alternative is to run a separate cross-compiled build for each<br>
>>> architecture. :-/<br>
>><br>
>><br>
>> Yes, this llvm-symbolizer part is frustrating... I though we can get away<br>
>> with it at first, as llvm-symbolizer is optional, and we generally won't be<br>
>> able<br>
>> to produce working *binaries* for architectures different from the host one<br>
>> (we might not have a linker, for instance).<br>
>> Android with its NDK looks like an exception, though.<br>
>><br>
>>><br>
>>><br>
>>><br>
>>> > Yes, so "ninja install" is optional.<br>
>>><br>
>>> But the 'install' depends on the 'all' target.<br>
>>><br>
>>> -Greg<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Fri, Mar 28, 2014 at 12:39 AM, Evgeniy Stepanov<br>
>>> <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
>>> > On Thu, Mar 27, 2014 at 10:18 PM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>><br>
>>> > wrote:<br>
>>> >>> Alexey's approach with CMake sub-projects.<br>
>>> >><br>
>>> >> I prefer that direction as well, but what I've proposed is a solution<br>
>>> >> that works today. To support cross-compilation, we'll need to loop<br>
>>> >> over each supported arch (llvm-config --targets-built), then loop over<br>
>>> >> each supported triple for each arch (hard-coded map?), and then pair<br>
>>> >> up each triple with a sysroot (system paths provided by the user).<br>
>>> >><br>
>>> >><br>
>>> >>> I think it already copies<br>
>>> >>> compiler-rt build products to the parent build directory, right?<br>
>>> >><br>
>>> >> The Android compiler-rt build does this, but in an unnecessarily<br>
>>> >> complex way. My proposal is a simplification of that process. What<br>
>>> >> is described in "llvm/cmake/platforms/Android.cmake" is to build<br>
>>> >> llvm+clang for the host architecture and then run a second build to<br>
>>> >> cross-compile llvm+compiler-rt to get a the ASan shared object and<br>
>>> >> test suite. Instead, I propose building only llvm for the host<br>
>>> >> architecture (for the purpose of building llvm-config) and then only<br>
>>> >> compile compiler-rt for Android. No need to build clang or to<br>
>>> >> cross-compile llvm.<br>
>>> >><br>
>>> >><br>
>>> >>> Requiring that llvm is installed complicates things.<br>
>>> >><br>
>>> >> Sorry for the confusion. By "llvm install directory", I don't mean to<br>
>>> >> install llvm to the root directory. I'm referring to the intermediary<br>
>>> >> directory pointed to by CMAKE_INSTALL_PREFIX. When you run "ninja<br>
>>> >> install", the build populates this directory with only the libs,<br>
>>> >> headers, docs, and executables that the LLVM build intends customers<br>
>>> >> to use directly. In the case of compiler-rt, we need LLVM's<br>
>>> >> "bin/llvm-config" to determine the build mode, flags, and targets<br>
>>> >> available.<br>
>>> ><br>
>>> > Yes, so "ninja install" is optional. This should work with LLVM build<br>
>>> > directory just as well.<br>
>>> ><br>
>>> >><br>
>>> >><br>
>>> >>> This should not be too hard to fix.<br>
>>> >><br>
>>> >> Porting the LLVM build to Android? That seems like a more challenging<br>
>>> >> solution than to cut out the unused cross-compiled llvm build.<br>
>>> ><br>
>>> > Note that ASan tests on Android require llvm-symbolizer binary.<br>
>>> > Building just compiler-rt for the target would not be enough.<br>
>>> ><br>
>>> >><br>
>>> >> -Greg<br>
>>> >><br>
>>> >> On Thu, Mar 27, 2014 at 1:14 AM, Evgeniy Stepanov<br>
>>> >> <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
>>> >>> I'd prefer something based on Alexey's approach with CMake<br>
>>> >>> sub-projects. I think it already copies compiler-rt build products to<br>
>>> >>> the parent build directory, right?<br>
>>> >>><br>
>>> >>> Requiring that llvm is installed complicates things.<br>
>>> >>><br>
>>> >>> On Thu, Mar 27, 2014 at 5:00 AM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>><br>
>>> >>> wrote:<br>
>>> >>>> The build for the Android sanitizers is unique in that it needs to<br>
>>> >>>> link against the Android system libraries to create a shared object<br>
>>> >>>> and its test suites. The current solution to build ASan is to drop<br>
>>> >>>> the compiler-rt repo into the llvm source tree and cross-compile the<br>
>>> >>>> llvm build for Android. This is a bit awkward for few reasons:<br>
>>> >>>><br>
>>> >>>> 1) Not all of llvm can be cross-compiled for Android. "ninja all"<br>
>>> >>>> causes expected build errors.<br>
>>> >>><br>
>>> >>> This should not be too hard to fix.<br>
>>> >>><br>
>>> >>>> 2) The sanitizers don't depend on any LLVM libraries, only<br>
>>> >>>> llvm-config<br>
>>> >>>> for its build configuration.<br>
>>> >>>> 3) No "install" rule. Instead, you cherry-pick files from the build<br>
>>> >>>> directory.<br>
>>> >>>><br>
>>> >>>> Building against the LLVM install directory cleans this up nicely and<br>
>>> >>>> as it turns out, this mostly works today (see CMake configuration<br>
>>> >>>> below). The only missing pieces are that the shared object is not<br>
>>> >>>> added to the install directory and the test suites are not built. Is<br>
>>> >>>> this a build configuration you'd consider using?<br>
>>> >>>><br>
>>> >>>> $ cmake -G Ninja .. \<br>
>>> >>>> -DCMAKE_INSTALL_PREFIX=ship \<br>
>>> >>>> -DCMAKE_C_COMPILER=arm-linux-androideabi-gcc \<br>
>>> >>>> -DCMAKE_CXX_COMPILER=arm-linux-androideabi-g++ \<br>
>>> >>>> -DCMAKE_PREFIX_PATH=`pwd`/../../llvm/out/ship \<br>
>>> >>>> -DANDROID=1 \<br>
>>> >>>> -DCMAKE_SYSTEM_NAME=Linux \<br>
>>> >>>> -DCMAKE_C_FLAGS=--sysroot=$(ndkDir)/platforms/android-19/arch-arm<br>
>>> >>>> \<br>
>>> >>>><br>
>>> >>>> -DCMAKE_CXX_FLAGS=--sysroot=$(ndkDir)/platforms/android-19/arch-arm<br>
>>> >>>> ...<br>
>>> >>>> $ ninja install<br>
>>> >>>> ...<br>
>>> >>>> [68/68]<br>
>>> >>>> -- Install configuration: "Release"<br>
>>> >>>> -- Installing: ship/include/sanitizer/asan_interface.h<br>
>>> >>>> -- Installing: ship/include/sanitizer/common_interface_defs.h<br>
>>> >>>> -- Installing: ship/include/sanitizer/dfsan_interface.h<br>
>>> >>>> -- Installing: ship/include/sanitizer/linux_syscall_hooks.h<br>
>>> >>>> -- Installing: ship/include/sanitizer/lsan_interface.h<br>
>>> >>>> -- Installing: ship/include/sanitizer/msan_interface.h<br>
>>> >>>> -- Installing: ship/include/sanitizer/tsan_interface_atomic.h<br>
>>> >>>> -- Installing: ship/asan_blacklist.txt<br>
>>> >>>> -- Installing: ship/bin/asan_device_setup<br>
>>> >>>><br>
>>> >>>> Thanks,<br>
>>> >>>> Greg<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Alexey Samsonov, MSK<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>