This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] Add platform detection support for x32
ClosedPublic

Authored by glaubitz on Apr 6 2021, 1:21 PM.

Details

Summary

Currently, the compiler-rt build system checks only whether X86_64
is defined to determine whether the default compiler-rt target arch
is x86_64. Since x32 defines
X86_64 as well, we must also check that
the default pointer size is eight bytes and not four bytes to properly
detect a 64-bit x86_64 compiler-rt default target arch.

Diff Detail

Event Timeline

glaubitz created this revision.Apr 6 2021, 1:21 PM
glaubitz requested review of this revision.Apr 6 2021, 1:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2021, 1:21 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
jrtc27 added inline comments.Apr 6 2021, 1:23 PM
compiler-rt/cmake/Modules/CompilerRTUtils.cmake
178–180

Should give an error if neither are true (see RISC-V)

glaubitz updated this revision to Diff 335649.Apr 6 2021, 1:30 PM
glaubitz marked an inline comment as done.
hvdijk added a comment.Apr 6 2021, 2:52 PM

Does this change mean the various *_SUPPORTED_ARCH need updating to list x32 as supported too, or are those handled separately?

Does this change mean the various *_SUPPORTED_ARCH need updating to list x32 as supported too, or are those handled separately?

I think x32 is not really supported by compiler-rt. With this patch, I can build clang stage2 with compiler-rt and libcxx enabled.

Without the patch, it fails with the linker trying to link x86_64 object code with x32 object code.

hvdijk added a comment.Apr 6 2021, 3:10 PM

I think x32 is not really supported by compiler-rt.

There's definitely support for x32 in libsanitizer, though I do not know how complete it is. libsanitizer is used by GCC as well and I am already using it with GCC on x32 myself.

I think x32 is not really supported by compiler-rt.

There's definitely support for x32 in libsanitizer, though I do not know how complete it is. libsanitizer is used by GCC as well and I am already using it with GCC on x32 myself.

I tried this additional change in the hope it would fix my original problem but that was not the case:

diff --git a/compiler-rt/cmake/base-config-ix.cmake b/compiler-rt/cmake/base-config-ix.cmake
index 1edab43e7c0d..12d9386989f3 100644
--- a/compiler-rt/cmake/base-config-ix.cmake
+++ b/compiler-rt/cmake/base-config-ix.cmake
@@ -168,9 +168,10 @@ macro(test_targets)
   elseif(NOT APPLE) # Supported archs for Apple platforms are generated later
     if(COMPILER_RT_DEFAULT_TARGET_ONLY)
       add_default_target_arch(${COMPILER_RT_DEFAULT_TARGET_ARCH})
-    elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "i[2-6]86|x86|amd64")
+    elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "i[2-6]86|x86|amd64|x32")
       if(NOT MSVC)
         test_target_arch(x86_64 "" "-m64")
+       test_target_arch(x32 "" "-mx32")
         test_target_arch(i386 __i386__ "-m32")
       else()
         if (CMAKE_SIZEOF_VOID_P EQUAL 4)

But I have to admit that I don't understand the compiler-rt code well enough to really know what to change.

The linker problem occurs when building stage2 with the following features -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;libcxx;libcxxabi;compiler-rt;lld;debuginfo-tests".

I will provide the build log snippet tomorrow.

Here is the error:

[ 98%] Linking CXX shared library ../lib/libc++.so
cd "/<<PKGBUILDDIR>>/libcxx/build/src" && /usr/bin/cmake -E cmake_link_script CMakeFiles/cxx_shared.dir/link.txt --verbose=1
"/<<PKGBUILDDIR>>/build-llvm/tools/clang/stage2-bins/bin/clang++" -fPIC -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -L/<<PKGBUILDDIR>>/libcxxabi/build/lib -shared -Wl,-soname,libc++.so.1 -o ../lib/libc++.so.1.0 CMakeFiles/cxx_shared.dir/algorithm.cpp.o CMakeFiles/cxx_shared.dir/any.cpp.o CMakeFiles/cxx_shared.dir/atomic.cpp.o CMakeFiles/cxx_shared.dir/barrier.cpp.o CMakeFiles/cxx_shared.dir/bind.cpp.o CMakeFiles/cxx_shared.dir/charconv.cpp.o CMakeFiles/cxx_shared.dir/chrono.cpp.o CMakeFiles/cxx_shared.dir/condition_variable.cpp.o CMakeFiles/cxx_shared.dir/condition_variable_destructor.cpp.o CMakeFiles/cxx_shared.dir/exception.cpp.o CMakeFiles/cxx_shared.dir/format.cpp.o CMakeFiles/cxx_shared.dir/functional.cpp.o CMakeFiles/cxx_shared.dir/future.cpp.o CMakeFiles/cxx_shared.dir/hash.cpp.o CMakeFiles/cxx_shared.dir/memory.cpp.o CMakeFiles/cxx_shared.dir/mutex.cpp.o CMakeFiles/cxx_shared.dir/mutex_destructor.cpp.o CMakeFiles/cxx_shared.dir/new.cpp.o CMakeFiles/cxx_shared.dir/optional.cpp.o CMakeFiles/cxx_shared.dir/random_shuffle.cpp.o CMakeFiles/cxx_shared.dir/shared_mutex.cpp.o CMakeFiles/cxx_shared.dir/stdexcept.cpp.o CMakeFiles/cxx_shared.dir/string.cpp.o CMakeFiles/cxx_shared.dir/system_error.cpp.o CMakeFiles/cxx_shared.dir/thread.cpp.o CMakeFiles/cxx_shared.dir/typeinfo.cpp.o CMakeFiles/cxx_shared.dir/utility.cpp.o CMakeFiles/cxx_shared.dir/valarray.cpp.o CMakeFiles/cxx_shared.dir/variant.cpp.o CMakeFiles/cxx_shared.dir/vector.cpp.o CMakeFiles/cxx_shared.dir/debug.cpp.o CMakeFiles/cxx_shared.dir/random.cpp.o CMakeFiles/cxx_shared.dir/ios.cpp.o CMakeFiles/cxx_shared.dir/ios.instantiations.cpp.o CMakeFiles/cxx_shared.dir/iostream.cpp.o CMakeFiles/cxx_shared.dir/locale.cpp.o CMakeFiles/cxx_shared.dir/regex.cpp.o CMakeFiles/cxx_shared.dir/strstream.cpp.o CMakeFiles/cxx_shared.dir/filesystem/operations.cpp.o CMakeFiles/cxx_shared.dir/filesystem/directory_iterator.cpp.o  -nostdlib++ -lpthread -lc -lm -lrt "/<<PKGBUILDDIR>>/build-llvm/tools/clang/stage2-bins/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a" -latomic -lc++abi
/usr/bin/x86_64-linux-gnux32-ld: i386:x86-64 architecture of input file `/<<PKGBUILDDIR>>/build-llvm/tools/clang/stage2-bins/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a(divti3.c.o)' is incompatible with i386:x64-32 output
/usr/bin/x86_64-linux-gnux32-ld: i386:x86-64 architecture of input file `/<<PKGBUILDDIR>>/build-llvm/tools/clang/stage2-bins/lib/clang/13.0.0/lib/linux/libclang_rt.builtins-x86_64.a(udivmodti4.c.o)' is incompatible with i386:x64-32 output
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [src/CMakeFiles/cxx_shared.dir/build.make:689: lib/libc++.so.1.0] Error 1
make[4]: Leaving directory '/<<PKGBUILDDIR>>/libcxx/build'
make[3]: *** [CMakeFiles/Makefile2:522: src/CMakeFiles/cxx_shared.dir/all] Error 2

It's obviously one of the typical x32-related errors again.

hvdijk added a comment.Apr 8 2021, 9:23 AM

Ah, that looks at first glance like not a compiler-rt problem but a clang problem, it will need to be taught the correct target name for x32 as well. If I'm right, that should be easy to fix, I can take a look later today or tomorrow.

Ah, that looks at first glance like not a compiler-rt problem but a clang problem, it will need to be taught the correct target name for x32 as well. If I'm right, that should be easy to fix, I can take a look later today or tomorrow.

OK, good to hear. Please subscribe me to the phabricator if you have patch :-).

glaubitz abandoned this revision.Apr 8 2021, 10:02 AM
glaubitz reclaimed this revision.Apr 9 2021, 5:24 AM
vitalybuka accepted this revision.Apr 16 2021, 9:35 AM
This revision is now accepted and ready to land.Apr 16 2021, 9:35 AM
hvdijk accepted this revision.Jun 10 2021, 3:46 PM

I've looked into which bits of compiler-rt already work for x32 and it's actually a lot, yet despite that it should not be enabled: what gets built for builtins works, but various functions that should be defined are left out, and the sanitizers that work depend on libunwind, which does not even build. So, I think it's fine to just go ahead and commit this as it then, and we can fix and enable things later on. (I'm working on that btw, but it'll be a while before anything's ready to be submitted.)

I've looked into which bits of compiler-rt already work for x32 and it's actually a lot, yet despite that it should not be enabled: what gets built for builtins works, but various functions that should be defined are left out, and the sanitizers that work depend on libunwind, which does not even build. So, I think it's fine to just go ahead and commit this as it then, and we can fix and enable things later on. (I'm working on that btw, but it'll be a while before anything's ready to be submitted.)

Cool, thanks a lot One step closer to finally get the Rust compiler working on x32 ;-).

@hvdijk Could you also later then commit the change for me? I don't have the necessary rights. Thanks!

This revision was automatically updated to reflect the committed changes.