compiler-rt linking failure on linux-sparcv9

Project Infrastructure LLVM Dev List Archives
1

Hi!

The build on linux-sparcv9 has recently started to fail with a linker failure that looks easy to
fix but so far I've been unable to find out where to include the necessary -latomic [1]:

/usr/bin/ld: warning: -z gnu-version-script-compat ignored
/usr/bin/ld: projects/compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic.sparc.dir/asan_allocator.cpp.o: in function `__sanitizer::atomic_uint64_t::Type __sanitizer::atomic_load<__sanitizer::atomic_uint64_t>(__sanitizer::atomic_uint64_t const volatile*, __sanitizer::memory_order)':
/home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:56: undefined reference to `__sync_fetch_and_add_8'
/usr/bin/ld: /home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:56: undefined reference to `__sync_fetch_and_add_8'
/usr/bin/ld: /home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:56: undefined reference to `__sync_fetch_and_add_8'
/usr/bin/ld: /home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:56: undefined reference to `__sync_fetch_and_add_8'
/usr/bin/ld: /home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:56: undefined reference to `__sync_fetch_and_add_8'
/usr/bin/ld: projects/compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic.sparc.dir/asan_allocator.cpp.o:/home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:56: more undefined references to `__sync_fetch_and_add_8' follow
/usr/bin/ld: projects/compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic.sparc.dir/asan_allocator.cpp.o: in function `void __sanitizer::atomic_store<__sanitizer::atomic_uint64_t>(__sanitizer::atomic_uint64_t volatile*, __sanitizer::atomic_uint64_t::Type, __sanitizer::memory_order)':
/home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:87: undefined reference to `__sync_val_compare_and_swap_8'
/usr/bin/ld: /home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:87: undefined reference to `__sync_val_compare_and_swap_8'
/usr/bin/ld: /home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:87: undefined reference to `__sync_val_compare_and_swap_8'
/usr/bin/ld: /home/glaubitz/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_atomic_clang_other.h:87: undefined reference to `__sync_val_compare_and_swap_8'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Does anyone have any suggestion where to add the necessary linker flags?

Full build log in [1].

Adrian

2

Hello!

The build on linux-sparcv9 has recently started to fail with a linker failure that looks easy to
fix but so far I've been unable to find out where to include the necessary -latomic [1]:

This was introduced by:

commit 3f7c3e84ad69f1ffa767b1b7ce3aa36de6c30f87 (refs/bisect/bad)
Author: Vitaly Buka <vitalybuka@google.com>

    [Asan] Fix __asan_update_allocation_context
    
    Update both thread and stack.
    Update thread and stack as atomic operation.
    Keep all 32bit of TID as now we have enough bits.
    
    Depends on D87135.
    
    Reviewed By: morehouse
    
    Differential Revision: ⚙ D87217 [Asan] Fix __asan_update_allocation_context

Any suggestions on how to fix this? Passing -latomic for the offending linker command doesn't
help, unfortunately.

A Linux SPARC porterbox (which I used for bisecting this) is available in the GCC compile farm [1].

Adrian

3

Hi!

The build on linux-sparcv9 has recently started to fail with a linker failure that looks easy to
fix but so far I've been unable to find out where to include the necessary -latomic [1]:

This was introduced by:

So, the build actually fails in the 32-bit libraries and I think the main problem is in [1]:

The way atomic_load/store on 32 bits are implemented is just weird. The code could just use
__atomic_load() and __atomic_store() [2].

The build doesn't fail on x86 and MIPS because these architectures have custom headers for
this code. Not sure about PPC but it looks like the code is disabled on PPC completely?

Adrian