X-Original-To: alpine-devel@mail.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id 207BADC1330 for ; Wed, 16 Mar 2016 21:16:02 +0000 (UTC) Received: from newmail.tetrasec.net (unknown [74.117.189.117]) by mail.alpinelinux.org (Postfix) with ESMTP id 01B06DC0D7E for ; Wed, 16 Mar 2016 21:16:01 +0000 (UTC) Received: from ncopa-desktop.alpinelinux.org (229.63.200.37.customer.cdi.no [37.200.63.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by newmail.tetrasec.net (Postfix) with ESMTPSA id 2A87E5A1541 for ; Wed, 16 Mar 2016 21:16:00 +0000 (GMT) Date: Wed, 16 Mar 2016 22:15:55 +0100 From: Natanael Copa To: alpine-devel@lists.alpinelinux.org Subject: [alpine-devel] long long alignment in clang for 64 bit atomic ops on x86 Message-ID: <20160316221555.541868ff@ncopa-desktop.alpinelinux.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Hi, When building lldb 3.8.0 on x86 i get alot of errors like: [ 86%] Linking CXX shared library ../../../../lib/liblldb.so CMakeFiles/liblldb.dir/SBAddress.cpp.o: In function `lldb::SBAddress::SBAddress(lldb::SBAddress const&)': /home/ncopa/aports/main/llvm/src/llvm-3.8.0.src/tools/lldb/source/API/SBAddress.cpp:(.text._ZN4lldb9SBAddressC2ERKS0_+0x53): undefined reference to `__atomic_load_8' CMakeFiles/liblldb.dir/SBAddress.cpp.o: In function `lldb::SBAddress::IsValid() const': /home/ncopa/aports/main/llvm/src/llvm-3.8.0.src/tools/lldb/source/API/SBAddress.cpp:(.text._ZNK4lldb9SBAddress7IsValidEv+0x24): undefined reference to `__atomic_load_8' CMakeFiles/liblldb.dir/SBAddress.cpp.o: In function `lldb::SBAddress::SetLoadAddress(unsigned long long, lldb::SBTarget&)': /home/ncopa/aports/main/llvm/src/llvm-3.8.0.src/tools/lldb/source/API/SBAddress.cpp:(.text._ZN4lldb9SBAddress14SetLoadAddressEyRNS_8SBTargetE+0xa1): undefined reference to `__atomic_load_8' /home/ncopa/aports/main/llvm/src/llvm-3.8.0.src/tools/lldb/source/API/SBAddress.cpp:(.text._ZN4lldb9SBAddress14SetLoadAddressEyRNS_8SBTargetE+0xbf): undefined reference to `__atomic_load_8' /home/ncopa/aports/main/llvm/src/llvm-3.8.0.src/tools/lldb/source/API/SBAddress.cpp:(.text._ZN4lldb9SBAddress14SetLoadAddressEyRNS_8SBTargetE+0xd1): undefined reference to `__atomic_store_8' CMakeFiles/liblldb.dir/SBAddress.cpp.o: In function `lldb::SBAddress::operator=(lldb::SBAddress const&)': /home/ncopa/aports/main/llvm/src/llvm-3.8.0.src/tools/lldb/source/API/SBAddress.cpp:(.text._ZN4lldb9SBAddressaSERKS0_+0x37): undefined reference to `__atomic_load_8' http://tpaste.us/A9nn I know we had that issue earlier when we used i486 target. The fix was to switch to i586 which has atomic instructions for 64 bit (at least it has atomic compare and exchange, cmpxchg8) I verified that the bootstrap compiler does use i586 target. That is ok. But it seems like clang (or llvm) does not support it anyway: https://llvm.org/bugs/show_bug.cgi?id=23262 There are also another bug about it: https://llvm.org/bugs/show_bug.cgi?id=24908 Which has an interesting comment at the end (comment 9): > The reason we decide to use a libcall is that we think the type is not sufficiently aligned. This change: > > X86_32TargetInfo(const llvm::Triple &Triple) : X86TargetInfo(Triple) { > - DoubleAlign = LongLongAlign = 32; > + DoubleAlign = 32; > + LongLongAlign = 64; > > also causes us to emit native IR. https://github.com/llvm-mirror/clang/blob/master/lib/Basic/Targets.cpp#L3726 When looking at that code, it looks like the windows 32 bit target use LongLongAlign = 64. https://github.com/llvm-mirror/clang/blolb/master/lib/Basic/Targets.cpp#L3849 I wonder if I can simply change it to 64 too? Or is that a really bad idea? I don't know the consequences of doing so. Alternatively, I suppose we can build clang, compiler-rt and lldb (and polly?) from separate package, using gcc instead of building those with a bootstrap clang. This is what fedora does. http://pkgs.fedoraproject.org/cgit/rpms/llvm.git/tree/llvm.spec http://pkgs.fedoraproject.org/cgit/rpms/clang.git/tree/clang.spec http://pkgs.fedoraproject.org/cgit/rpms/compiler-rt.git/tree/compiler-rt.spec http://pkgs.fedoraproject.org/cgit/rpms/lldb.git/tree/lldb.spec A third option is to simply exclude lldb on x86 for now. What do you think? -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---