Re: [PULL 00/35] MIPS patches for 2021-01-03

[Peter Maydell]

On Tue, 5 Jan 2021 at 09:36, Philippe Mathieu-Daudé <f4bug@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