[SR-5779] SwiftRuntimeTests target fails on FreeBSD due to a linker error #48349
Comments
|
Some other informations, for completeness: Swift Revision: commit 8675c8e719e0896a4a37a6fdd87fafb4a2ea5283
Merge: f52b19238c 7fd9e0bb04
Author: swift-ci <swift-ci@users.noreply.github.com>
Date: Sun Aug 27 12:47:35 2017 -0700
Merge pull request #​11650 from salmanjamil/patch-1Clang version on the host: FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/binuname: FreeBSD mercat6.netperf.freebsd.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #​0: Fri May 26 04:11:44 UTC 2017 root@mercat6.netperf.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 |
|
I'm under the impression this may be a variation of: I'll try to get that sorted out in LLVM, but I wonder if there's something that can be done on the swift-side to workaround this problem for the time being. |
|
Maybe |
|
Hi Jordan. |
|
Hm, maybe it's supposed to be something in compiler-rt then. If it really is just the SwiftRuntimeTests target, it doesn't seem like trouble to add an extra library to link against on BSD systems. |
|
Comment by Zac (JIRA) I'm having the same problem but in libswiftCore.so. Both _*sync_lock_test_and_set_16 and *_sync_val_compare_and_swap_16 are emitted as externally imported symbols but are neither are available as I don't have libstdc++ on my platform. |
|
Comment by Zac (JIRA) I've done some investigating. It comes from SwiftShims/HeapObjects.cpp calls to compare_exchange_weak on the C++ atomic wrapper around refCounts. I've been digging deep and it seems like TargetLoweringBase.cpp in LLVM is emitting a library call for the atomic swap and compare instead of using some builtin to try and do it with RTLIB::Libcall. /code/xxx/buildtools/linux-x64/clang/bin/lld: error: undefined symbol: __sync_val_compare_and_swap_16 RTLIB::Libcall is called in two places and I'm not sure which is causing this bug. Looking into LLVM LegalizeDAG.cpp calls ConvertNodeToLibcall which uses RTLIB::Libcall. Also LegalizeIntegerTypes.cpp's DAGTypeLegalizer::ExpandIntegerResult also calls RTLIB::Libcall on this case. |
|
Comment by Zac (JIRA) I figured out what it is. The cmake build scripts for Linux and other archs does not set a target arch when building libswiftCore. Clang when building files with <atomic> will assume that CMPXCHG16B is not available on your target intel arch because some random old AMDs did not have it and will force libcall for those intrinsics. On Linux this more just accidently resolves to a library that is emitting libatomics methods dynamically (probably libstdc++) and libswiftCore resolves to it. On a system without any GNU stack (like you are using compiler-rt) you are screwed. You have to change the swift built to add -mc16 as a cflag (or a -march that implies that feature is supported) when building swift libraries which will fix everything. |
|
> On a system without any GNU stack (like you are using compiler-rt) you are screwed. |
|
Can you try applying this to your local LLVM checkout and see if if fixes the problem? Thanks, -- |
Additional Detail from JIRA
md5: 041350be3b8c017938f67d832db77dcf
Issue Description:
Now that I have some time, I'm trying to revamp the FreeBSD support in swift.
I'm seeing a bunch of linker errors when running basic tests (specifying `-t` to `build-script`).
The text was updated successfully, but these errors were encountered: