From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLACK,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73F81C433E0 for ; Tue, 5 Jan 2021 15:16:27 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 11CE022B45 for ; Tue, 5 Jan 2021 15:16:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11CE022B45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=amsat.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:39628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwo4Q-0004GP-4G for qemu-devel@archiver.kernel.org; Tue, 05 Jan 2021 10:16:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwo2j-0003ag-Hs for qemu-devel@nongnu.org; Tue, 05 Jan 2021 10:14:41 -0500 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:36286) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kwo2e-0002yr-It for qemu-devel@nongnu.org; Tue, 05 Jan 2021 10:14:38 -0500 Received: by mail-wm1-x32a.google.com with SMTP id y23so3397218wmi.1 for ; Tue, 05 Jan 2021 07:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=n8wxZqed5AUobsiDm4bNOoFDW1b3eZQ5Z/U0Af9kF1Q=; b=vhQZ4xEvFF/QdTgURtUfaDZIcy/CGbanH4AQKwHpzEN885phAYA7UV72NzK/U921fO rbE88ZFUAPFbwKqQrnPUoNrwEMw2CQiRPI+5NkC9NXVMYAVtUakj+jk+5W/3d2Fe/Eyr 6x/5oTu2zIUuUsaSTZI3AZoEiSidRWigwsTbUWaQafiU77u8OptcPKdyrKTw6sAbDyki jKQ5GfSPD24LWlXtx0Rf+WB7LHbxb55cWfhvzfZmySbL3qcncBIfwXctF/20saEaH3zD LlEFTuIG3hQ1ay4uskTaFOT+FrYM4tjP4EY2Pn+SciWsqR1iB1OI30+0YejoLxUA/5NX o3/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n8wxZqed5AUobsiDm4bNOoFDW1b3eZQ5Z/U0Af9kF1Q=; b=SOmtvBBbBAZSI+y2qRJeWQrg3bsTuArxuKUPOtmR3bVLapHjTy1uz9rklNjOGf5dPb gM9CSwe+Kehw1yO5wLdIInAb8ysJW4J79mvMKxTPDSGiBu2UQDfc/MiFyAZrYWkdj9tv AA/ZRLNjBwv1O1hSl15T3jysICDikAdJ/8hhm1anUzPF6xMyJHolvkA/HjwMgX3SDOnW J0kKUySPIru1YdCD+M15Jx5dtG1eqOAs7FxDyMMpUFrbkiZv3KQh/eRsOomJNsCQAeRz DvWDVtBhgZpNZ43oYxT4QGfcXhHaspzPZAMDoVhp60ecIhAOuXoc+T3xpnV8S3rNLK2F Osfg== X-Gm-Message-State: AOAM530ebDB5HoOA2/wzMAv50Gk3enwea1EaKuj1XJyGt0PFOCvrCxIr GPv+C0kukSWwq5P1kWM0hLI= X-Google-Smtp-Source: ABdhPJyCRMkMvXYWYx189ADpbkkiaegbVrRrZ3fMa6ypxgkmI5/Kkbb11CH16X13JYDKLruhfUw5dg== X-Received: by 2002:a1c:1c1:: with SMTP id 184mr3915889wmb.112.1609859674581; Tue, 05 Jan 2021 07:14:34 -0800 (PST) Received: from [192.168.1.36] (241.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.241]) by smtp.gmail.com with ESMTPSA id s133sm4508760wmf.38.2021.01.05.07.14.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Jan 2021 07:14:33 -0800 (PST) Subject: Re: [PULL 00/35] MIPS patches for 2021-01-03 To: Peter Maydell , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Stefan Hajnoczi , "Emilio G. Cota" References: <20210103205021.2837760-1-f4bug@amsat.org> <790b031a-2be6-82d0-565d-f7595e95c077@amsat.org> <47b22eb2-8600-b34f-371f-517804b9cb49@amsat.org> <07a865e0-d535-9a19-cf29-f90984bcd510@amsat.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Message-ID: Date: Tue, 5 Jan 2021 16:14:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=philippe.mathieu.daude@gmail.com; helo=mail-wm1-x32a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Huacai Chen , QEMU Developers , Gerd Hoffmann , Paolo Bonzini , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Aurelien Jarno , Richard Henderson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 1/5/21 2:17 PM, Peter Maydell wrote: > On Tue, 5 Jan 2021 at 09:36, Philippe Mathieu-Daudé 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. That makes sense. So on a Ubuntu 18.04 i386 host, "configure --cc=clang-10 --enable-sanitizers' sets atomic64=yes (__ATOMIC_RELAXED is also defined). The ./configure check is simple. There is a lot of ifdef'ry to follow in "qemu/osdep.h" and "qemu/compiler.h" so it is hard to figure out what changes "qemu/atomic.h" that it doesn't match with ./configure. Maybe a issue with the sanitizer code? Cc'ing Stefan, Emilio & Marc-André too :)