On Tue, 5 Jan 2021 at 09:36, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: > 4/ libatomic on 32-bit hosts (i386, riscv32? arm?) > > While compiling succeed, linking fails: > > [850/2216] Linking target tests/test-hbitmap > FAILED: tests/test-hbitmap > clang -o tests/test-hbitmap tests/test-hbitmap.p/test-hbitmap.c.o > tests/test-hbitmap.p/iothread.c.o -Wl,--as-needed -Wl,--no-undefined > -pie -Wl,--whole-archive libblock.fa libcrypto.fa libauthz.fa libqom.fa > libio.fa -Wl,--no-whole-archive -Wl,--warn-common -fsanitize=undefined > -fsanitize=address -Wl,-z,relro -Wl,-z,now -m32 -ggdb > -fstack-protector-strong -Wl,--start-group libqemuutil.a > subprojects/libvhost-user/libvhost-user-glib.a > subprojects/libvhost-user/libvhost-user.a libblock.fa libcrypto.fa > libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 > -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lutil -lgnutls > -lm -lgthread-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libglib-2.0.so > -liscsi -lgthread-2.0 -lglib-2.0 -laio -lcurl > /usr/lib/i386-linux-gnu/libz.so -lrbd -lrados -lnettle -lgnutls > -Wl,--end-group > libblock.fa(block_io.c.o): In function `stat64_max': > include/qemu/stats64.h:58: undefined reference to `__atomic_load_8' > include/qemu/stats64.h:60: undefined reference to > `__atomic_compare_exchange_8' > libblock.fa(block_qapi.c.o): In function `stat64_get': > include/qemu/stats64.h:40: undefined reference to `__atomic_load_8' > libqemuutil.a(util_qsp.c.o): In function `qatomic_set_u64': > include/qemu/atomic.h:478: undefined reference to `__atomic_store_8' > libqemuutil.a(util_qsp.c.o): In function `qatomic_read_u64': > include/qemu/atomic.h:468: undefined reference to `__atomic_load_8' > clang: error: linker command failed with exit code 1 (use -v to see > invocation)
Historically we have not linked against libatomic on purpose, on the theory that QEMU should not be trying to use atomic operations that the compiler cannot directly open-code as native atomic instructions. (This is because we want things to work even if the code in another thread that might also be doing atomic operations on the data is TCG.) libatomic might choose to use a mutex under the hood, if my understanding/memory is correct, which obviously TCG won't. In particular this means that code that can run on 32-bit hosts is not supposed to be doing 64-bit atomic operations. For the code in stat64_max/stat64_get, this is guarded by CONFIG_ATOMIC64, which configure should only be setting if we can do 64-bit atomics without libatomic, so looking at whether that got set and if the test is doing the wrong thing would be my first suggestion. thanks -- PMM
