This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt][Android] Stop using detect_target_arch
ClosedPublic

Authored by rprichard on Jun 18 2020, 11:51 PM.

Details

Summary

For Android only, compiler-rt used detect_target_arch to select the
architecture to target. detect_target_arch was added in Sept 2014
(SVN r218605). At that time, compiler-rt selected the default arch
using ${LLVM_NATIVE_ARCH}, which seems to have been the host
architecture and therefore not suitable for cross-compilation.

The compiler-rt build system was refactored in Sept 2015 (SVN r247094
and SVN r247099) to use COMPILER_RT_DEFAULT_TARGET_TRIPLE to control
the target arch rather than LLVM_NATIVE_ARCH. This approach is simpler
and also works for Android cross-compilation, so remove the
detect_target_arch function.

Android targets i686, but compiler-rt seems to identify 32-bit x86 as
"i386". For Android, we were previously calling add_default_target_arch
with i386, and calling add_default_target_arch with i686 does not build
anything. i686 is not listed in builtin-config-ix.cmake,
ALL_BUILTIN_SUPPORTED_ARCH.

Diff Detail

Event Timeline

rprichard created this revision.Jun 18 2020, 11:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 18 2020, 11:51 PM
Herald added subscribers: Restricted Project, s.egerton, simoncook and 5 others. · View Herald Transcript

This Android-specific call to detect_target_arch is apparently the only call. It was originally added in https://reviews.llvm.org/rL218605.

I think that something changed or there is some misunderstanding. You are absolutely correct about the compiler runtime dependency. However, the symbol being checked here is _not_ a compile check, its a preprocessor check. Those are architectural macros that CPP is expected to provide. We should fix that instead.

LLVM's detect_target_arch is using check_symbol_exists, which is provided by CMake itself and uses try_compile to build and link a test executable.

CMake's desire to link an executable when that isn't possible breaks a few other things:

  • CMake implicitly checks whether the compiler is working, so it must be overridden, e.g.: D39715
  • The unwind.h detection breaks, so the __gcc_personality_v0 routine might be incorrectly omitted.

There is a CMAKE_TRY_COMPILE_TARGET_TYPE variable that can be set to STATIC_LIBRARY to disable the linking. It looks like it's currently used in libunwind. D70815, D71117.

The new variable was added after LLVM's current minimum version of CMake 3.4.3. (However, it looks like Android's build system is using CMake 3.17, so it could probably set CMAKE_TRY_COMPILE_TARGET_TYPE when it invokes cmake on lib/builtins/CMakeLists.txt.)

It looks like compiler-rt defines a try_compile_only macro that skips linking. Maybe compiler-rt could have preprocessor symbol detection that uses try_compile_only, but I think we want to remove try_compile_only after the next CMake version bump (http://lists.llvm.org/pipermail/llvm-dev/2019-October/136370.html).

The detect_target_arch function is only used for Android, so it seemed simple to remove it and have the Android build more closely resemble other configurations. I'm not sure why we did it this way to begin with, though. That's something I could dig into.

compnerd accepted this revision.Jul 6 2020, 3:14 PM

Hmm, I think that an explanation of why it was this way originally along with the explanation that you just gave that this is specific to android and that this change would unify the behaviour between the various targets, sounds like a good approach to me. For some reason I was under the impression that this was shared with Linux as well. But, I do agree with you, that if its actually making everything more similar, it is better. Please do update the commit message with the additional information before merging, but otherwise, LGTM.

This revision is now accepted and ready to land.Jul 6 2020, 3:14 PM
rprichard edited the summary of this revision. (Show Details)Jul 10 2020, 1:50 AM

Passing -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY fixes detect_target_arch and unwind.h autodetection, so I don't strictly need this revision anymore. It is a nice simplification, though, so I'll still commit it. I did some digging to figure out why detect_target_arch was needed. When it was added in 2014, the compiler-rt target selection was based on LLVM_NATIVE_ARCH, which appears to have been the host architecture, so not suitable for cross-compilation.

e.g. From rL218605:

 # Generate the COMPILER_RT_SUPPORTED_ARCH list.
 if(ANDROID)
-  test_target_arch(arm_android "")
+  # Can't rely on LLVM_NATIVE_ARCH in cross-compilation.
+  # Examine compiler output instead.
+  detect_target_arch()
+  set(COMPILER_RT_OS_SUFFIX "-android")
 else()
   if("${LLVM_NATIVE_ARCH}" STREQUAL "X86")
     if (NOT MSVC)
       test_target_arch(x86_64 ${TARGET_64_BIT_CFLAGS})
     endif()
     test_target_arch(i386 ${TARGET_32_BIT_CFLAGS})
   elseif("${LLVM_NATIVE_ARCH}" STREQUAL "PowerPC")
     test_target_arch(powerpc64 ${TARGET_64_BIT_CFLAGS})
   elseif("${LLVM_NATIVE_ARCH}" STREQUAL "Mips")
     test_target_arch(mips "")
   endif()
   # Build ARM libraries if we are configured to test on ARM
   if("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "arm|aarch64")
     test_target_arch(arm "-march=armv7-a")
     test_target_arch(aarch64 "-march=armv8-a")
   endif()
+  set(COMPILER_RT_OS_SUFFIX "")
 endif()
This revision was automatically updated to reflect the committed changes.
dmajor added a subscriber: dmajor.Jul 14 2020, 12:37 PM

Hi, this commit seems to have caused a problem in Firefox. We're no longer getting a libclang_rt.profile-arm-android.a in our clang package when we request armv7-linux-android. Does arm need special translation similar to the i686->i386 special case?

We're also getting issues due to this, aarch64/arm targets no longer exist in android-aarch64/build.ninja.
See https://crbug.com/1105568.

Will revert soon since multiple people are complaining.

Confirmed that reverting this fixes the issue, reverted in bef00b244c3140558c574cc106771b0f2452ef84.

The revert fixes our build too. Just in time for the 11.0.0 branch, thanks @aeubanks!