In Rust CI, while trying to upgrade to LLVM 11 rc1, arm-unknown-linux-gnueabi failed to link lld due to missing symbols for Timer.cpp: https://github.com/rust-lang/rust/pull/73526#issuecomment-671549737 > [100%] Linking CXX executable ../../bin/lld > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: ../../lib/liblldCommon.a(Timer.cpp.o): in function `lld::ScopedTimer::stop()': > Timer.cpp:(.text._ZN3lld11ScopedTimer4stopEv+0x44): undefined reference to `__atomic_fetch_add_8' > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: ../../lib/liblldCommon.a(Timer.cpp.o): in function `lld::Timer::millis() const': > Timer.cpp:(.text._ZNK3lld5Timer6millisEv+0x8): undefined reference to `__atomic_load_8' > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: ../../lib/liblldCommon.a(Timer.cpp.o): in function `lld::Timer::print(int, double, bool) const': > Timer.cpp:(.text._ZNK3lld5Timer5printEidb+0x2c0): undefined reference to `__atomic_load_8' > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: ../../lib/liblldCommon.a(Timer.cpp.o): in function `lld::Timer::print()': > Timer.cpp:(.text._ZN3lld5Timer5printEv+0x34): undefined reference to `__atomic_load_8' This can be solved by linking libatomic on targets that need it. I've tried to add this in https://reviews.llvm.org/D85691, but it seems that the use of atomics for Timer at all is controversial.
I'm trying to work out if there is a problem with LLD here, or with the command-line option that it is given. It isn't possible to work this out with the bug details, and I'm not sure anyone is going to go to the trouble to work it out from the Rust CI system. For the former it would imply that there is a dependency on libatomic encoded in the inputs that LLD is not picking up on but ld.bfd is. Perhaps we've missed a DT_NEEDED or a file masquerading as a linker script. Would it be possible to make a reproducer lld --reproduce=<file.tar> is a good way to do this although bugzilla file size limits usually mean the file has to be hosted somewhere else.
@Peter the issue here is not LLD itself but linking LLD with ld.bfd. Since https://reviews.llvm.org/D80298 LLD fails to compile on the targets which need to link libatomic explicitly.
My apologies, thanks for clarifying, and thanks for pointing out https://reviews.llvm.org/D80298 that makes it much clearer. Peter
D85691 is now committed, but I think this should be included in 11.0.0 too.
Cherry-picked to 11.x as 1708358fbbf58d4a870be015ef21eeea9adae87b. Thanks!