Skip to content

Use LLVM runtimes build #60993

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 12 commits into from
Closed

Conversation

edymtt
Copy link
Contributor

@edymtt edymtt commented Sep 8, 2022

LLVM plans to remove the legacy methods for building compiler-rt. This change updates build-script to use LLVM_ENABLE_RUNTIMES to build compiler-rt with the just-built clang instead of the legacy methods.

(cherry picked from #58465 to double check my suggestion is sound)

LLVM plans to remove the legacy methods for building compiler-rt. This
change updates build-script to use LLVM_ENABLE_RUNTIMES to build
compiler-rt with the just-built clang instead of the legacy methods.

(cherry picked from commit 6386f60)
@edymtt
Copy link
Contributor Author

edymtt commented Sep 8, 2022

@swift-ci please build toolchain

@edymtt
Copy link
Contributor Author

edymtt commented Sep 8, 2022

@swift-ci please test

@edymtt
Copy link
Contributor Author

edymtt commented Sep 8, 2022

@swift-ci please test

@edymtt
Copy link
Contributor Author

edymtt commented Sep 8, 2022

@swift-ci please build toolchain

@edymtt
Copy link
Contributor Author

edymtt commented Sep 8, 2022

@swift-ci Please Test Source Compatibility Release

@edymtt
Copy link
Contributor Author

edymtt commented Sep 8, 2022

It looks like under Linux we started detecting i386 as an architecture we can build for, and then we stumble finding missing headers/libraries

-- Looking for __i386__
-- Looking for __i386__ - found
-- Builtin supported architectures: i386;x86_64
<snip>
FAILED: CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o 
/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./bin/clang --target=x86_64-unknown-linux-gnu -DVISIBILITY_HIDDEN  -O3 -DNDEBUG  -m32 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o -MF CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o.d -o CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o -c /home/build-user/llvm-project/compiler-rt/lib/builtins/absvdi2.c
In file included from /home/build-user/llvm-project/compiler-rt/lib/builtins/absvdi2.c:13:
In file included from /home/build-user/llvm-project/compiler-rt/lib/builtins/int_lib.h:93:
In file included from /home/build-user/build/buildbot_linux/llvm-linux-x86_64/lib/clang/13.0.0/include/limits.h:21:
/usr/include/limits.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
#include <bits/libc-header-start.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Trying to figure out why that's the case.

@edymtt
Copy link
Contributor Author

edymtt commented Sep 28, 2022

@swift-ci please test

@edymtt
Copy link
Contributor Author

edymtt commented Sep 28, 2022

@swift-ci please test Linux

@edymtt
Copy link
Contributor Author

edymtt commented Sep 30, 2022

Figured out the failure was due to the fact that the configuration of builtins compiles archives to detect compiler features, and so we assume we can compile for x86 even if we miss the libraries on the bots

https://reviews.llvm.org/D91334

@edymtt
Copy link
Contributor Author

edymtt commented Sep 30, 2022

@swift-ci please test

@edymtt
Copy link
Contributor Author

edymtt commented Sep 30, 2022

Now hitting some troubles building libclang_rt.tsan.so

/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25
compiler-rt/lib/tsan/rtl/CMakeFiles/clang_rt.tsan-dynamic-x86_64.dir/tsan_interceptors_libdispatch.cpp.o: in function `__tsan::dispatch_callback_wrap(void*)':
tsan_interceptors_libdispatch.cpp:(.text._ZN6__tsanL22dispatch_callback_wrapEPv+0x62): undefined reference to `dispatch_queue_offsets'
/usr/bin/ld: compiler-rt/lib/tsan/rtl/CMakeFiles/clang_rt.tsan-dynamic-x86_64.dir/tsan_interceptors_libdispatch.cpp.o: in function `__interceptor_dispatch_async':
tsan_interceptors_libdispatch.cpp:(.text.__interceptor_dispatch_async+0x8f): undefined reference to `_Block_copy'
/usr/bin/ld: compiler-rt/lib/tsan/rtl/CMakeFiles/clang_rt.tsan-dynamic-x86_64.dir/tsan_interceptors_libdispatch.cpp.o: in function `__tsan::invoke_and_release_block(void*)':
tsan_interceptors_libdispatch.cpp:(.text._ZN6__tsanL24invoke_and_release_blockEPv+0xc): undefined reference to `_Block_release'
<snip>

They will fail linking since we are not building the runtimes with
`-Wl,-z,defs`, which will fail in presence of undefined symbols in the
final `libclang_rt.tsan` library.
@edymtt
Copy link
Contributor Author

edymtt commented Oct 3, 2022

@swift-ci please test

@edymtt
Copy link
Contributor Author

edymtt commented Oct 3, 2022

The failure seems to be caused by the fact that with the runtimes builds we are now linking the sanitizer libraries with -Wl,-z,defs, so now the linker complains about undefined symbols related to dispatch/BlocksRuntime.

@edymtt
Copy link
Contributor Author

edymtt commented Oct 3, 2022

Getting another regression in Linux when running integration tests

+ python3 /home/build-user/llvm-project/llvm/utils/lit/lit.py . -sv --param package-path=/home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64 --param test-exec-root=/home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64/tests --param llvm-bin-dir=/home/build-user/build/buildbot_linux/llvm-linux-x86_64/bin
~/swift-integration-tests ~
-- Testing: 31 tests, 31 workers --
<snip>
FAIL: swift-package-tests :: test-codecov-package/test-codecov-package.txt (30 of 31)
******************** TEST 'swift-package-tests :: test-codecov-package/test-codecov-package.txt' FAILED ********************
error: link command failed with exit code 1 (use -v to see invocation)
<snip>
clang version 13.0.0 (https://github.com/apple/llvm-project.git c3aebe50177cd03e8ec426c8e337efd6157b571d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64/usr/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Candidate multilib: .;@m64
Selected multilib: .;@m64
clang-13: error: no such file or directory: '/home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64/usr/lib/swift/clang/lib/linux/libclang_rt.profile-x86_64.a'
error: fatalError


--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
********************
Failed Tests (1):
  swift-package-tests :: test-codecov-package/test-codecov-package.txt

@edymtt
Copy link
Contributor Author

edymtt commented Oct 3, 2022

@edymtt
Copy link
Contributor Author

edymtt commented Oct 3, 2022

@swift-ci please test Linux

@edymtt
Copy link
Contributor Author

edymtt commented Oct 3, 2022

@swift-ci please test Linux

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci please test

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci Please Test Source Compatibility Release

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci please build toolchain

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci please test Apple Silicon

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci Please ASAN test

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci Please test CentOS 7 platform

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci Please test CentOS 8 platform

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

@swift-ci Please test Amazon Linux 2 platform

@edymtt
Copy link
Contributor Author

edymtt commented Oct 4, 2022

Just realized now that LLVM_ENABLE_RUNTIMES may remain in caches and cause trouble with other PR testing.

Tackling this in #61435

# We are now inheriting the -Wl,-z,defs linker flags
# from HandleLLVMOptions.cmake, so the compiler now complains
# for BlocksRuntime symbols that are undefined
-DCOMPILER_RT_INTERCEPT_LIBDISPATCH:BOOL=OFF
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be turned off, otherwise we will break TSan. @edymtt

Can we fix the undefined references by linking the blocks runtime -fblocks?

The CMake code here is trying to do this:
https://github.com/llvm/llvm-project/blob/f418f88824905c372cb9252b3f675012a3fc799d/compiler-rt/CMakeLists.txt#L172

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try explore that -- to the best of my understanding that is not present in CI nodes, and we are building that ourselves when we are building Swift, but likely I'm missing something

@edymtt
Copy link
Contributor Author

edymtt commented Jan 31, 2024

Duplicate of #67986

@edymtt edymtt marked this as a duplicate of #67986 Jan 31, 2024
@edymtt edymtt closed this Jan 31, 2024
@edymtt edymtt deleted the use-runtimes-build-bis branch January 31, 2024 22:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants