[yadcc ARM] spinlock 在 arm 构建中找不到符号 __aarch64_swp1_acq

[fish2bird]

flare/flare/base/thread/BUILD

Line 162 in 64d72fc

srcs = 'spinlock.cc',

在 arm 上构建 yadcc 的时候报错

gcc-10.3.0/include/c++/10.3.0/bits/atomic_base.h:443: undefined reference to `__aarch64_swp1_acq'

经查此符号只在 libatomic.a 中有，似乎 gcc 与 atomic 关系有点复杂， 临时规避后继续通行

diff --git a/flare/base/thread/BUILD b/flare/base/thread/BUILD
index 60e4805..9a2bed7 100644
--- a/flare/base/thread/BUILD
+++ b/flare/base/thread/BUILD
@@ -163,6 +163,9 @@ cc_library(
   deps = [
     '//flare/base:likely',
   ],
+  linkflags = [
+    '-Wl,-Bstatic -latomic -Wl,-Bdynamic',
+  ],
   visibility = 'PUBLIC',
 )

[0x804d8000]

这个gcc是自己编译的吗？

印象里atomic的实现方式有两种，一种是直接生成ll/sc，一种是用libatomic（这个性能略差），具体选择哪个可能跟gcc的configure的参数有关。

centos8 aarch64带的gcc我记得应该是不用链接libatomic的。你可以看下你的环境的gcc是不是配置有什么不一样的地方。

[fish2bird]

这个gcc是自己编译的吗？

印象里atomic的实现方式有两种，一种是直接生成ll/sc，一种是用libatomic（这个性能略差），具体选择哪个可能跟gcc的configure的参数有关。

centos8 aarch64带的gcc我记得应该是不用链接libatomic的。你可以看下你的环境的gcc是不是配置有什么不一样的地方。

是自己构建的，环境为 glibc 2.28 请看看是否正常

Using built-in specs.
COLLECT_GCC=/***/gcc-11.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/***/gcc-11.3.0/libexec/gcc/aarch64-redhat-linux/11.3.0/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ./configure --prefix=/***/gcc-11.3.0 --build=aarch64-redhat-linux --enable-threads=posix --enable-multiarch --disable-checking --enable-long-long --disable-multilib --enable-languages=c,c++,fortran --with-mpc=/***/mpc-1.2.1 --with-gmp=/***/gmp-6.2.1 --with-mpfr=/***/mpfr-4.1.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (GCC)

[0x804d8000]

看起来没什么明显的问题。

我手上现在没有aarch64的环境，但是有这么一些想法：

• 可以尝试直接编译一个简单的、使用了std::atomic的代码，看看反汇编是不是直接生成了ldrex/strex或其他的类似的原子指令。是的话则不需要libatomic。我看godbolt上面的arm-gcc是这样的。
• 可以尝试编译gcc时configure的时候指定--disable-libatomic看看有没有区别。
• 可以尝试给gcc指定不同的-march看看会不会影响原子操作的codegen，有可能默认target到了某个很老的ISA，让gcc不得不依赖libatomic来实现原子操作。

[fish2bird]

我用简单的尝试了下， 同样的 configure 参数， gcc9及以前都是直接展开了原子指令， 但是 gcc 10 起使用了函数调用，除非开启 -mno-outline-atomics

https://godbolt.org/z/z8W7z1cqx

不过发现并不需要显式链接静态库， 这应该是我的环境有多个 gcc ，搞混了导致， 也就是这个 BUILD 补丁是不必要的

网上类似问题 cloudius-systems/osv#1129