This is an archive of the discontinued LLVM Phabricator instance.

Allow the builting of the builtins library with a forced compiler.
AbandonedPublic

Authored by vkalintiris on Sep 24 2015, 6:01 AM.

Details

Reviewers
samsonov
beanz
Summary

When we are trying to create a new LLVM-based toolchain, without using a GCC
toolchain, we don't have a fully-working compiler in the beginning. So, we have
to force the usage of the C compiler and assume that the CMAKE invocation
includes the correct C flags in order to build compiler-rt.

Diff Detail

Event Timeline

vkalintiris retitled this revision from to Allow the builting of the builtins library with a forced compiler..
vkalintiris updated this object.
vkalintiris added a reviewer: samsonov.
vkalintiris added a subscriber: llvm-commits.
samsonov edited edge metadata.Oct 5 2015, 5:13 PM

Sorry for the delayed review. I don't yet understand this patch. What is your CMake invocation, and why doesn't CMake succeeds in verifying the host compiler?

What is your CMake invocation, ...

cmake -G Ninja -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_C_COMPILER=mips-mti-linux-clang -DCMAKE_C_FLAGS='-EB -mabi=32 -target mips-mti-linux -mips32r2 -mhard-float -fPIC -nostdlib' -DCMAKE_C_COMPILER_FORCED=True -DCMAKE_CXX_COMPILER_FORCED=True -DCMAKE_SIZEOF_VOID_P=4 -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=mips-r2-hard-musl -DCOMPILER_RT_BUILD_SANITIZERS=Off /home/vk/repos/compiler-rt

and why doesn't CMake succeeds in verifying the host compiler?

Because I'm trying to build a mips-mti-linux toolchain from scratch (see D13340). This toolchain does not depend on the existence of a GCC installation. The first thing that I have to build is the builtins component from compiler-rt. After that I can build the C library (musl in my case), libcxx, libcxxabi, etc. So, at this point, without C/C++ libraries, CMake can not perform any reasonable test that depends on the compiler. This invocation of CMake is the minimal one that allows me to build the builtins library. Although it's ugly, I'm not aware of any other possible solution with CMake.

I see. I think you should instead update test_target_arch macro to support your use case: if arch we're testing is the same as COMPILER_RT_DEFAULT_TARGET_ARCH, and it was set explicitly, and we have CMAKE_C_COMPILER_FORCED, then we can add arch to the list of supported arches instead of printing a fatal error (assuming that user knows better).

Will the build actually work without any standard libraries?

if arch we're testing is the same as COMPILER_RT_DEFAULT_TARGET_ARCH, and it was set explicitly, and we have CMAKE_C_COMPILER_FORCED, then we can add arch

How can I test whether COMPILER_RT_DEFAULT_TARGET_ARCH was set explicitly? In my case, TARGET_TRIPLE = COMPILER_RT_DEFAULT_TARGET_TRIPLE and thus COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE=False (when I explicitly specify COMPILER_RT_DEFAULT_TARGET_TRIPLE=mips-mti-linux in the cmake command line).

Other than that, I believe that what you suggested should be working for me.

Will the build actually work without any standard libraries?

Yes. For the builtins library, we only need the kernel headers and the headers from the C library.

if arch we're testing is the same as COMPILER_RT_DEFAULT_TARGET_ARCH, and it was set explicitly, and we have CMAKE_C_COMPILER_FORCED, then we can add arch

How can I test whether COMPILER_RT_DEFAULT_TARGET_ARCH was set explicitly? In my case, TARGET_TRIPLE = COMPILER_RT_DEFAULT_TARGET_TRIPLE and thus COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE=False (when I explicitly specify COMPILER_RT_DEFAULT_TARGET_TRIPLE=mips-mti-linux in the cmake command line).

Oh, ok. Then you probably can just allow arch in test_target_arch if it's the same as COMPILER_RT_DEFAULT_TARGET_ARCH, and CMAKE_C_COMPILER_FORCED is set.

Other than that, I believe that what you suggested should be working for me.

Will the build actually work without any standard libraries?

Yes. For the builtins library, we only need the kernel headers and the headers from the C library.

vkalintiris edited edge metadata.

Update test_target_arch macro to recognize <arch> as supported when we
want to build the builtins library with a forced C compiler.

vkalintiris added inline comments.Oct 30 2015, 6:10 AM
cmake/config-ix.cmake
110

I placed the check here because we don't want to use the pre-configured TARGET_${arch}_CFLAGS. Additionally, I check that we don't build the sanitizers libraries because that would require a working C++ compiler.

beanz added a reviewer: beanz.Nov 2 2015, 9:19 AM
beanz added a subscriber: beanz.

The same basic problem you're having here was reported on IRC last week during the LLVM dev meeting. I've started a thread on llvm-dev to discuss this problem and possible solutions. I'm not completely opposed to this as a temporary solution, but it actually won't work for most cases.

In the normal CMake cross-compiling process you won't get anywhere near this far through configuring the build because all of the try_compile and check_cxx_compiler_flag calls will fail. I assume the only reason that isn't biting you is because you're not actually cross-compiling via a CMake toolchain, you're relying on the hacked-in cross compiling capabilities in Compiler-RT's build.

I do not want to block you from making progress, but I think it would be best for the project if we can at least discuss the long-term solution to this problem before we talk about temporary workarounds.

I would encourage you to participate in the discussion, the thread is: http://lists.llvm.org/pipermail/llvm-dev/2015-November/091916.html

Thanks,
-Chris

The same basic problem you're having here was reported on IRC last week during the LLVM dev meeting. I've started a thread on llvm-dev to discuss this problem and possible solutions. I'm not completely opposed to this as a temporary solution, but it actually won't work for most cases.

In the normal CMake cross-compiling process you won't get anywhere near this far through configuring the build because all of the try_compile and check_cxx_compiler_flag calls will fail. I assume the only reason that isn't biting you is because you're not actually cross-compiling via a CMake toolchain, you're relying on the hacked-in cross compiling capabilities in Compiler-RT's build.

I do not want to block you from making progress, but I think it would be best for the project if we can at least discuss the long-term solution to this problem before we talk about temporary workarounds.

I would encourage you to participate in the discussion, the thread is: http://lists.llvm.org/pipermail/llvm-dev/2015-November/091916.html

Thanks,
-Chris

The initial version of this review request is simple enough for me to maintain in our out-of-tree repositories. However, if the "right" solution to this problem is going to take too long, eg. more than say 6 months, it would be nice to have something upstream in order to avoid resolving conflicts manually. Also, given the intention to fix this, the initial version of the review request would be preferable to hacking the test_target_arch macro. More on the thread at llvm-dev :)

vkalintiris abandoned this revision.Feb 16 2016, 3:25 AM

Dropped in favour of Chris' changes that will fix this.