Subject: [alpine-devel] long long alignment in clang for 64 bit atomic ops on x86

From: Natanael Copa <[email-masked]>
Date: Wed, 16 Mar 2016 22:15:55 +0100

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:  [email-masked]
Help:         [email-masked]
---