[{"id":3675279,"web_url":"http://patchwork.ozlabs.org/comment/3675279/","msgid":"","list_archive_url":null,"date":"2026-04-09T12:14:35","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":93091,"url":"http://patchwork.ozlabs.org/api/people/93091/","name":"Gyorgy Tamasi","email":"gyorgy.tamasi@gmail.com"},"content":"Tested-by: Gyorgy Tamasi \n\nAdditional independent testing (bug + fix cases) is documented here -\nsee comments by sourav/@kishu279:\nhttps://gitlab.com/qemu-project/qemu/-/work_items/3371\n\nOn Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n wrote:\n>\n> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n> > In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n> > TARGET_LOONGARCH64 are defined!) we can not use the struct\n> > target_stat64 for data-transfer, since this struct target_stat64 is\n> > defined for 32bit environments with its int-sized (4byte) st_*time\n> > sec/nsec components.\n> > The user side compiler headers of the LoongArch64 env uses long-sized\n> > (8byte) st_*time sec/nsec components.\n> >\n> > (This is similar to the case of 32bit vs. 64bit RISCV: the original\n> > code does not use struct target_stat64 in 64bit RISCV env, when both\n> > TARGET_RISCV and TARGET_RISCV64 are defined.)\n> >\n> > This fix is important for LoongArch64 ABI1.0, where stat() is using an\n> > fstatat syscall with this struct target_stat64, if its usage is\n> > enabled.\n> > (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n> > problematic struct target_stat64 is not used, struct statx is correct\n> > in the LoongArch64 env.)\n> > See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> >\n> > Signed-off-by: Gyorgy Tamasi \n> > ---\n> > linux-user/syscall_defs.h | 2 +-\n> > 1 file changed, 1 insertion(+), 1 deletion(-)\n> >\n>\n> Reviewed-by: Pierrick Bouvier ","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=dP4yTZtm;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frzRB1Yvqz1yCv\n\tfor ; Thu, 09 Apr 2026 22:15:32 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wAoHb-0002xq-Og; Thu, 09 Apr 2026 08:14:51 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wAoHY-0002ws-A5\n for qemu-devel@nongnu.org; Thu, 09 Apr 2026 08:14:48 -0400","from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wAoHW-0001P0-KC\n for qemu-devel@nongnu.org; Thu, 09 Apr 2026 08:14:48 -0400","by mail-lf1-x12a.google.com with SMTP id\n 2adb3069b0e04-5a0ff30b240so1052688e87.0\n for ; Thu, 09 Apr 2026 05:14:46 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1775736884; cv=none;\n d=google.com; s=arc-20240605;\n b=AqTW5QtTH7eslWL5F2jgayIfIMDvqKqCcp6C3qnEX+tbMzRXhHlRn1b/Z+rT9JV0ZN\n j36DqzdW/s5fgRci1kg3rpffISNYpeXr194nPi25q3G2Y7CIzYT0+jyXubEPxMjKe0ci\n sPohl9kI7Z1J6tqf4U+0J44e+IfCeVHdkGh0mjP6PmVygPrNtj/pvLNugDKCJeW5D5Yr\n s7K0C7w6ywsbmq0CMFHf1BnkBYEEbXBWffsw1/TXW5n8bxsPq7mfbKxfwpqKyHgCvDvj\n +S8DgHCEDrZYwz1zMLpTFi39+A+bYAPBA2F4NNV8ZLaquW5U7jBusAVeUtkYDoOlglU3\n 6Lrw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=GQ2QLRC2q4nCs8Ix6HIfoqeh1t1V7GUWmwnYj6Hr1rM=;\n fh=Mhn3iCZUwUHrsfmkOmDR9xkZAHbThDVH63k510t4Ymw=;\n b=j4uZvmyH/YoK8VUAsl5gRPj8T/eOBH3OHVhLFVCgwLQePPIE+t3hYzHTpzDapF/qR4\n EMcBmUJLa8bT5kJACvmo14qbO3JKCBV2HT/Ezxg2v+iIAOLdLvKQT8BFbLsFbo+EByuM\n 1/3yMCyl97yqzhST8TVNgWVoJ7Wk1Xe8FJ5RJCoCFG8HtXDOPCXv0Re7vt3efgNwDYOD\n mKSG+xee3JA1kxbAjM3FZDkEGFo2QX0Y/bpjBxN5Mnvtx8dfzNEcEjB0p6yFV9mM6WJk\n Q+Iv7hhjLLSHodnEOqTk6hUJCilbDfivdhjxJzsgML/sMD6nIWYE10mLOhylGkwr4dS/\n 8/dg==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775736884; x=1776341684; darn=nongnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=GQ2QLRC2q4nCs8Ix6HIfoqeh1t1V7GUWmwnYj6Hr1rM=;\n b=dP4yTZtmHfMyAmHXxLtPkSI7F+ViM4CQdV7/bQn0LhWbZs9pkvcZ7opEiK2FJXPQhc\n tr8RHuOjI1SGUQbZUwA0U1k9RF3ytBhvh3lwevZAxbtofIZws2NIXzB7wwGKIrxCqoyL\n Gqg7OiVrt851rc7+sJSxaC/I8BVmtOb7Tzhv5LZGA2DqLaIs3LFQtNwjRBr7Gi90QTpP\n 1/tE/SN6Del3MSRndKHY4xsDFoURl0ivu/HrmtsnUEbOh8j9+G6hbZWa3PuTs0GkAu/O\n k7Hwg66trV02kgMx0FQSeZ4bZUCAdGJFlYP2H1yXSKwDWhnA10q0uS8x5Bm53FKKnGAi\n etaQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775736884; x=1776341684;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=GQ2QLRC2q4nCs8Ix6HIfoqeh1t1V7GUWmwnYj6Hr1rM=;\n b=TSe5r0XET59vtyqqLeIBOccvtAuJDd5GxU7jZDG15YdGBJjIx1re9FM3qXqE7+sCCk\n cyceHlEw6964W+/8qfP/QCKb0be2Oo87j0Ft8LMVh6qQCDRS1vLmM9/QSkrTpuAj4PQm\n WAz26PmYlkQHMqaQ5PaprvnfaFNQZmTUdv0rKIbg4lUEslh+5JLRq2DM8hKWW4nWqikz\n KEdOI1I97edfIZX/QjeFdP+z8Ye9yZOP7unITbYqv7Rqw6IEv6qYphIKnMjFZy/dDlYf\n AQdaq2ngw8hQR60LKEvu05r+Sm1A0YEYF/6NJMWAq5FospRcWMs0UtCjR3HSBCdq9IEa\n RlQQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCWtLCr7CxYHVkVNAt5Txp52m5GQwmwy6uy3+vq2xGlWVT1q9rL+pCteF2uZIzVUItexg42jc42YIR99@nongnu.org","X-Gm-Message-State":"AOJu0Yz/i6pA25i0aEDY/N8s7N8fe43fICvf7xCsc0eSCM5UAowJ+RfD\n oY4FGDq47VbV2LIk6hVLba+KhLbTaLy86nYzJF5CrKFCsn1UGM/4PxaNuOodWcLNmlyCSg5H+Wb\n vq9QQ4LnvNWPuP8Ix2WXY3ZH6aAGsWRU=","X-Gm-Gg":"AeBDievuhLRxTPB1tHKqxHxFssz2GHhp+P+wxWV0iOBSXDaaZoSQWnCt9HTZrMdSQP8\n a0hayUukglSRPPqyUVSXA/J7yxw/bxtzQfuzV24bpL8Z43Srr0vaqSjab3pmb5++sUBP0ojwrF4\n eudJdcxwsyCm+ooACmBiQcqtXZVqcEOQ7Bbx2Zk+LcJwbBLOTmww8H/cRTojGxok90dW1LbfvTP\n AYubbUPc7ddMhUkzPhXwMmaAurQ4UQ9PPisVAyGDh/zKonaTz6VJe4+uZryRzQn7WmgERf7VIBV\n l5cFwwIucHn8wu41CM5GARi5SKHeOTiEZ2FtnsHVlguuljJEUbo=","X-Received":"by 2002:a05:6512:3a92:b0:5a2:8571:459e with SMTP id\n 2adb3069b0e04-5a337566ef7mr9314082e87.13.1775736883967; Thu, 09 Apr 2026\n 05:14:43 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n ","In-Reply-To":"","From":"Gyorgy Tamasi ","Date":"Thu, 9 Apr 2026 14:14:35 +0200","X-Gm-Features":"AQROBzCTnHcgliZbIiCuNrAXGgg5mu1IMi78KMQF-GSSQVVvy9Tfkk2VeHBfegg","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Pierrick Bouvier ","Cc":"laurent@vivier.eu, qemu-devel@nongnu.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=2a00:1450:4864:20::12a;\n envelope-from=gyorgy.tamasi@gmail.com; helo=mail-lf1-x12a.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3675758,"web_url":"http://patchwork.ozlabs.org/comment/3675758/","msgid":"","list_archive_url":null,"date":"2026-04-10T09:38:06","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":82024,"url":"http://patchwork.ozlabs.org/api/people/82024/","name":"Song Gao","email":"gaosong@loongson.cn"},"content":"在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n> Tested-by: Gyorgy Tamasi \n>\n> Additional independent testing (bug + fix cases) is documented here -\n> see comments by sourav/@kishu279:\n> https://gitlab.com/qemu-project/qemu/-/work_items/3371\n\nHi.\nPlease note that QEMU is not compatible with ABI 1.0.\n\nIf you absolutely must use ABI 1.0, the branch below is the version we use.\nhttps://github.com/loongson/qemu/commits/9.2-tcg-old/\n \nHowever, this branch is quite far from the mainline.\nThe QEMU mainline follows the kernel mainline, and\nI believe this is the case for other architectures as well.\n\nThanks.\nSong Gao\n> On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n> wrote:\n>> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n>>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n>>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n>>> target_stat64 for data-transfer, since this struct target_stat64 is\n>>> defined for 32bit environments with its int-sized (4byte) st_*time\n>>> sec/nsec components.\n>>> The user side compiler headers of the LoongArch64 env uses long-sized\n>>> (8byte) st_*time sec/nsec components.\n>>>\n>>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n>>> code does not use struct target_stat64 in 64bit RISCV env, when both\n>>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n>>>\n>>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n>>> fstatat syscall with this struct target_stat64, if its usage is\n>>> enabled.\n>>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n>>> problematic struct target_stat64 is not used, struct statx is correct\n>>> in the LoongArch64 env.)\n>>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>>>\n>>> Signed-off-by: Gyorgy Tamasi \n>>> ---\n>>> linux-user/syscall_defs.h | 2 +-\n>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>>\n>> Reviewed-by: Pierrick Bouvier ","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsWtn6DnTz1yGb\n\tfor ; Fri, 10 Apr 2026 19:37:52 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wB8Iq-0000mv-AX; Fri, 10 Apr 2026 05:37:28 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wB8In-0000mh-Ur\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 05:37:25 -0400","from mail.loongson.cn ([114.242.206.163])\n by eggs.gnu.org with esmtp (Exim 4.90_1)\n (envelope-from ) id 1wB8Ik-00021S-VG\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 05:37:25 -0400","from loongson.cn (unknown [10.20.42.239])\n by gateway (Coremail) with SMTP id _____8BxFMG+xNhpg_IjAA--.52717S3;\n Fri, 10 Apr 2026 17:37:02 +0800 (CST)","from [10.20.42.239] (unknown [10.20.42.239])\n by front1 (Coremail) with SMTP id qMiowJAxHMKsxNhpP0RqAA--.4348S3;\n Fri, 10 Apr 2026 17:36:52 +0800 (CST)"],"Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Gyorgy Tamasi ,\n Pierrick Bouvier ","Cc":"laurent@vivier.eu, qemu-devel@nongnu.org,\n Peter Maydell ,\n Richard Henderson ,\n Huacai Chen , bibo mao ,\n xianglai li ","References":"\n \n \n ","From":"gaosong ","Message-ID":"","Date":"Fri, 10 Apr 2026 17:38:06 +0800","User-Agent":"Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101\n Thunderbird/68.7.0","MIME-Version":"1.0","In-Reply-To":"\n ","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","X-CM-TRANSID":"qMiowJAxHMKsxNhpP0RqAA--.4348S3","X-CM-SenderInfo":"5jdr20tqj6z05rqj20fqof0/","X-Coremail-Antispam":"1Uk129KBj93XoW7ZF48GrWkZF43Cw4DJry7urX_yoW8ury3pF\n WxCay2krW5JrW3Ca1DKFy7uFWYgrn3J345WrWjgr4Y9as0vry5tr40g3y5uFyDZayxCF4Y\n 9r47C3sxWFWqyagCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa\n sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU\n 0xBIdaVrnRJUUUv2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2\n IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v\n e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI\n 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK\n xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx\n 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv\n 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07\n AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02\n F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GF\n ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj\n xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r\n 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8xu\n ctUUUUU==","Received-SPF":"pass client-ip=114.242.206.163;\n envelope-from=gaosong@loongson.cn;\n helo=mail.loongson.cn","X-Spam_score_int":"-49","X-Spam_score":"-5.0","X-Spam_bar":"-----","X-Spam_report":"(-5.0 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-3.135,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3676105,"web_url":"http://patchwork.ozlabs.org/comment/3676105/","msgid":"","list_archive_url":null,"date":"2026-04-11T02:08:51","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":93091,"url":"http://patchwork.ozlabs.org/api/people/93091/","name":"Gyorgy Tamasi","email":"gyorgy.tamasi@gmail.com"},"content":"Hi,\n\nThanks for the link of this separate Loongson-maintained 9.2-tcg-old\nbranch - intended for use specifically with ABI 1.0 code.\n\nThis separate branch still contains the same bug (in the context of\nthe glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\nfstatat syscall can be used by glibc, and it can trigger the usage of\nthe related erroneous data-conversion workflow based on struct\ntarget_stat64 with 4byte sec/nsec fields):\n\nThis changeset was the last mod of syscall_defs.h - but it still\nincorrectly modifies the condition of struct target_stat64 usage:\n(~ \"Add Loongarch64 old ABI support\")\nhttps://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n(line 2006)\n-----\n-#if !defined(TARGET_RISCV64)\n+#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n-----\n\nThis is the broader context in this 9.2-tcg-old original version:\nHere the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\nno-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\nis true/false.\n-----\n#elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n defined(TARGET_LOONGARCH64)\n/* These are the asm-generic versions of the stat and stat64 structures */\n\n#define TARGET_STAT_HAVE_NSEC\nstruct target_stat {\n...\n};\n\n#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n#define TARGET_HAS_STRUCT_STAT64\nstruct target_stat64 {\n...\n};\n#endif\n\n#elif defined(TARGET_HPPA)\n-----\n\nThe correct fix is the same here (~ disable the use of this struct\ntarget_stat64 - instead of explicitly enabling it for\nTARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n-----\n~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n--- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n+++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n@@ -2003,7 +2003,7 @@\n abi_uint __unused5;\n };\n\n-#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n+#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n #define TARGET_HAS_STRUCT_STAT64\n struct target_stat64 {\n abi_ullong st_dev;\n-----\n\nThe same test-scenario of\nhttps://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n[with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\ntoolset] to show exactly the same bad & good test results - without &\nwith this mod.\n\nJust a personal experience based side-note on ABI1.0 compatibility\nwith mainline qemu (~10.2.2):\nI'm working on porting a quite large code-base (a commercial OCR &\ndocument conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\nI'm trying to check correctness of my actual builds using the\nregression-test package of this codebase. It runs quite complex\nworkflows of general CLI code. I accept that this is not a\ncomprehensive test with all of the edge cases or touching every\nspecial areas (like signal handling) of compatibility of ABI1.0 and\nmainline qemu, but...the ABI1.0 version of this test-code seems to be\nable to run with mainline qemu-user 10.2.2.\n\nBest regards,\n-tgy\n\nOn Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n>\n> 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n> > Tested-by: Gyorgy Tamasi \n> >\n> > Additional independent testing (bug + fix cases) is documented here -\n> > see comments by sourav/@kishu279:\n> > https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>\n> Hi.\n> Please note that QEMU is not compatible with ABI 1.0.\n>\n> If you absolutely must use ABI 1.0, the branch below is the version we use.\n> https://github.com/loongson/qemu/commits/9.2-tcg-old/\n>\n> However, this branch is quite far from the mainline.\n> The QEMU mainline follows the kernel mainline, and\n> I believe this is the case for other architectures as well.\n>\n> Thanks.\n> Song Gao\n> > On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n> > wrote:\n> >> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n> >>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n> >>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n> >>> target_stat64 for data-transfer, since this struct target_stat64 is\n> >>> defined for 32bit environments with its int-sized (4byte) st_*time\n> >>> sec/nsec components.\n> >>> The user side compiler headers of the LoongArch64 env uses long-sized\n> >>> (8byte) st_*time sec/nsec components.\n> >>>\n> >>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n> >>> code does not use struct target_stat64 in 64bit RISCV env, when both\n> >>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n> >>>\n> >>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n> >>> fstatat syscall with this struct target_stat64, if its usage is\n> >>> enabled.\n> >>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n> >>> problematic struct target_stat64 is not used, struct statx is correct\n> >>> in the LoongArch64 env.)\n> >>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> >>>\n> >>> Signed-off-by: Gyorgy Tamasi \n> >>> ---\n> >>> linux-user/syscall_defs.h | 2 +-\n> >>> 1 file changed, 1 insertion(+), 1 deletion(-)\n> >>>\n> >> Reviewed-by: Pierrick Bouvier \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=ThQ+8SrB;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsxvX2XwCz1yGb\n\tfor ; Sat, 11 Apr 2026 12:09:58 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wBNmY-0006AI-Bs; Fri, 10 Apr 2026 22:09:10 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wBNmW-0006A1-CW\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 22:09:09 -0400","from mail-lf1-x131.google.com ([2a00:1450:4864:20::131])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wBNmT-00084F-O2\n for qemu-devel@nongnu.org; Fri, 10 Apr 2026 22:09:07 -0400","by mail-lf1-x131.google.com with SMTP id\n 2adb3069b0e04-5a3cee3a271so2562846e87.3\n for ; Fri, 10 Apr 2026 19:09:04 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1775873342; cv=none;\n d=google.com; s=arc-20240605;\n b=VMp0WYw7qULBZwgZ844ioX9NP/bV26eOTL1PgpKgZItychLv5s2RGSeV943k6ZYSqG\n lWE0VHD/6JwoA39uaaOmuyquwMtblQtZzyKiySXRLQeTWL+wWgQoJNDqB424pxMftYeD\n Uthw4LG+Kke6o5z90E6cF19VR5KoFhJ6ZlqDEks1sDoKUVhlZz2pc2pnQAsUkkk7NU2P\n MtjwlxdZgkODvDU+jp+Q1AuqkI6xPrC5h+NWpB89YD9NKtA6uhcsMpykmglABspqpotK\n MZV3FGNQkM4AAMHng8ztRjDn5Kcdqs3w44fWrooZeuWWSBG4arG+ULNCZgkfYY7rkahD\n Sndw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=emP0HUw1kmwMJB9K+bSDDHdQ82d2fvGcDIhF7rssWhI=;\n fh=cS4bk7BExldfdP+Pj39w1jWPjlqGv2d/xO67F7d3QG0=;\n b=TJ4N7j1oD3IxeICzr4S2BUDfsiz9wYEYMfKyLRrVYWsXx9fW/+04PDA7DjAZN0Jq9f\n qlGPyeNPO0ICaSr91YcWHqvxFG78ZgxqMVAKAYd3u6bmmWj3Ctk7NN8o+HjYusmaOoKf\n 9lgUHOqTl7seqW3AtWE/AZNS6Ek4ggjWuGe+wFPoVulPAzCyvvoPH0PnI5A/R9DRlSuJ\n lRXadItJYuAMsSoTSRinUTKbOblB+OS8LP0/jD+hzJgcDFEltS956WiN0BEzMH+CZNr4\n lmwoBWqFYoeQ/4aSPLcbY+oThnU2F4j1+4ccEXgvIqxAwkCpDHulbRfOHRQXbtx1gi+Q\n lEKA==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775873342; x=1776478142; darn=nongnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=emP0HUw1kmwMJB9K+bSDDHdQ82d2fvGcDIhF7rssWhI=;\n b=ThQ+8SrBSqlkSTZt5KrzbuoNx/RVfzcGImGWMfSYWhvXt3kItlz5EZndndiN1N/S/k\n LKZtgXOj+KAzUoVa7j7R8pgsqjH9n2AdZbvI6NkOV7MeNNdoLUPST4M9kHwd6s6Y8P5T\n mT9er/1DJ4/whfUNAOV6vksqlJW6zPi3nhlFybrRa23ebOlAYcOrix5MRBkIqKTxHgWO\n /LZioxocNoc0Ktmvjyj4yv0MjwU4gycZDeubeEmloJuQ33TRORX0+q6g2lGOpjTqCwMQ\n PQgeF/ERsyrfJyN87uz24QSS68C80Kjrb7Sr3uRlWCGiNd8bzeACbv0FdkKY5+bn6M2b\n eFDg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775873342; x=1776478142;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=emP0HUw1kmwMJB9K+bSDDHdQ82d2fvGcDIhF7rssWhI=;\n b=X3upf1MZjQeUpnGjI/6CxxodVWhaMjPvY8GEdz5lQzSsToQtZ0ZOVyTwu5UXoc6UpH\n PT58n2CIrPV3c9TyBaU3eUv8Sf15+GDGuQ4ZTYbqeBlisTJUhg/ynZKSASTGT9M/DagD\n paEqH7g9zW7tIBLeBnu257+qjkDSiFiuU2r0CVlF1bu6MINKFfdzUxY1virhZA8lTLNr\n D17PympeO3iVYFps3A+J058SGqo/lmBIDkrAKCb+itvhkvHSAWoe7VbYXq9N13fONoNQ\n xoSn/NoMqtYptjwW0SojVYwPXEt8LXW7rQACO9rRxhspt+KMP2/raLZrZam4RuE+uudc\n AQTA==","X-Forwarded-Encrypted":"i=1;\n AJvYcCX9LBE9uYtWq+/QnaZzIfVUwoKBWsNq0lOwyFQVQiZlBQM2V1b9w6C+fsorcvcd3ajehr3UO0o929F1@nongnu.org","X-Gm-Message-State":"AOJu0YxqK7fHSEPJIsKL7+9Xz8QsATg0l63NJ4nSKt08ONOtLAhgIkTx\n s1T+2Sl/XSmIWlkxOiXFW2+KS87YWBZ5GlVFnjyK6aJWKgTK8b3a82ZIGUjuVZ1fbDes3X1+afE\n MmOMrw7Uv7CX8gOWl5gFklpS0Y8tOoi8=","X-Gm-Gg":"AeBDiesAlQI1vi4bYl7wqLn2fvGHzWk7G62yKKPFIyQUZCT8qluSJm2Li5SA9uenDSh\n VlL8zQd3P+TqOCOwk3EAxRl5K4S7Y8ZFkxHlJiEvOIopKBI5xbglWM6IULOLHDvRgZOwghmXRsM\n OWkCXT1Vd5j/VlnmoxJY0ZBs3bntZUdaS8UqmWrFfv68cujA+s4qxW1g9OuJI8q7ffvP45tEm4t\n 5TFXzWN0d/sdCde9+AHHFXb7H1m6rtxQPtQOqsTh1e0TqGXC4gr2F5TyrwEm7LaacWJww1jL1NV\n R9jM6fa8qHoJ1AS+yBUUGfLlEx8hyygg3rr3pg8V","X-Received":"by 2002:a05:6512:10d4:b0:5a2:cac3:5271 with SMTP id\n 2adb3069b0e04-5a3efe8ebf4mr1773543e87.42.1775873342035; Fri, 10 Apr 2026\n 19:09:02 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n ","In-Reply-To":"","From":"Gyorgy Tamasi ","Date":"Sat, 11 Apr 2026 04:08:51 +0200","X-Gm-Features":"AQROBzBGPSDs7LYhao9mqEwLs8FhyLBv5VNpA5_PUfJkaPVGrj_j10FoJKgRFs8","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"gaosong ","Cc":"Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Peter Maydell ,\n Richard Henderson ,\n Huacai Chen , bibo mao ,\n xianglai li ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=2a00:1450:4864:20::131;\n envelope-from=gyorgy.tamasi@gmail.com; helo=mail-lf1-x131.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3676126,"web_url":"http://patchwork.ozlabs.org/comment/3676126/","msgid":"","list_archive_url":null,"date":"2026-04-11T08:24:28","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":80791,"url":"http://patchwork.ozlabs.org/api/people/80791/","name":"Huacai Chen","email":"chenhuacai@kernel.org"},"content":"On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi wrote:\n>\n> Hi,\n>\n> Thanks for the link of this separate Loongson-maintained 9.2-tcg-old\n> branch - intended for use specifically with ABI 1.0 code.\n>\n> This separate branch still contains the same bug (in the context of\n> the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\n> fstatat syscall can be used by glibc, and it can trigger the usage of\n> the related erroneous data-conversion workflow based on struct\n> target_stat64 with 4byte sec/nsec fields):\n>\n> This changeset was the last mod of syscall_defs.h - but it still\n> incorrectly modifies the condition of struct target_stat64 usage:\n> (~ \"Add Loongarch64 old ABI support\")\n> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n> (line 2006)\n> -----\n> -#if !defined(TARGET_RISCV64)\n> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\nI think this patch has nothing to do with ABI 1.0/2.0, it really fixed\na bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n\nHuacai\n\n> -----\n>\n> This is the broader context in this 9.2-tcg-old original version:\n> Here the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\n> no-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\n> is true/false.\n> -----\n> #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n> || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n> defined(TARGET_LOONGARCH64)\n> /* These are the asm-generic versions of the stat and stat64 structures */\n>\n> #define TARGET_STAT_HAVE_NSEC\n> struct target_stat {\n> ...\n> };\n>\n> #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> #define TARGET_HAS_STRUCT_STAT64\n> struct target_stat64 {\n> ...\n> };\n> #endif\n>\n> #elif defined(TARGET_HPPA)\n> -----\n>\n> The correct fix is the same here (~ disable the use of this struct\n> target_stat64 - instead of explicitly enabling it for\n> TARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n> -----\n> ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n> --- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n> +++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n> @@ -2003,7 +2003,7 @@\n> abi_uint __unused5;\n> };\n>\n> -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n> #define TARGET_HAS_STRUCT_STAT64\n> struct target_stat64 {\n> abi_ullong st_dev;\n> -----\n>\n> The same test-scenario of\n> https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n> [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\n> toolset] to show exactly the same bad & good test results - without &\n> with this mod.\n>\n> Just a personal experience based side-note on ABI1.0 compatibility\n> with mainline qemu (~10.2.2):\n> I'm working on porting a quite large code-base (a commercial OCR &\n> document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\n> I'm trying to check correctness of my actual builds using the\n> regression-test package of this codebase. It runs quite complex\n> workflows of general CLI code. I accept that this is not a\n> comprehensive test with all of the edge cases or touching every\n> special areas (like signal handling) of compatibility of ABI1.0 and\n> mainline qemu, but...the ABI1.0 version of this test-code seems to be\n> able to run with mainline qemu-user 10.2.2.\n>\n> Best regards,\n> -tgy\n>\n> On Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n> >\n> > 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n> > > Tested-by: Gyorgy Tamasi \n> > >\n> > > Additional independent testing (bug + fix cases) is documented here -\n> > > see comments by sourav/@kishu279:\n> > > https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> >\n> > Hi.\n> > Please note that QEMU is not compatible with ABI 1.0.\n> >\n> > If you absolutely must use ABI 1.0, the branch below is the version we use.\n> > https://github.com/loongson/qemu/commits/9.2-tcg-old/\n> >\n> > However, this branch is quite far from the mainline.\n> > The QEMU mainline follows the kernel mainline, and\n> > I believe this is the case for other architectures as well.\n> >\n> > Thanks.\n> > Song Gao\n> > > On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n> > > wrote:\n> > >> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n> > >>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n> > >>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n> > >>> target_stat64 for data-transfer, since this struct target_stat64 is\n> > >>> defined for 32bit environments with its int-sized (4byte) st_*time\n> > >>> sec/nsec components.\n> > >>> The user side compiler headers of the LoongArch64 env uses long-sized\n> > >>> (8byte) st_*time sec/nsec components.\n> > >>>\n> > >>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n> > >>> code does not use struct target_stat64 in 64bit RISCV env, when both\n> > >>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n> > >>>\n> > >>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n> > >>> fstatat syscall with this struct target_stat64, if its usage is\n> > >>> enabled.\n> > >>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n> > >>> problematic struct target_stat64 is not used, struct statx is correct\n> > >>> in the LoongArch64 env.)\n> > >>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> > >>>\n> > >>> Signed-off-by: Gyorgy Tamasi \n> > >>> ---\n> > >>> linux-user/syscall_defs.h | 2 +-\n> > >>> 1 file changed, 1 insertion(+), 1 deletion(-)\n> > >>>\n> > >> Reviewed-by: Pierrick Bouvier \n> >","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=II3SqzEv;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4ft6DP65qjz1y2d\n\tfor ; Sat, 11 Apr 2026 18:25:08 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wBTds-0008Uf-JM; Sat, 11 Apr 2026 04:24:36 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wBTdr-0008UX-Fq\n for qemu-devel@nongnu.org; Sat, 11 Apr 2026 04:24:35 -0400","from tor.source.kernel.org ([172.105.4.254])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wBTdp-0005UV-FT\n for qemu-devel@nongnu.org; Sat, 11 Apr 2026 04:24:35 -0400","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by tor.source.kernel.org (Postfix) with ESMTP id CAA4260145\n for ; Sat, 11 Apr 2026 08:24:23 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 59F09C2BCB1\n for ; Sat, 11 Apr 2026 08:24:23 +0000 (UTC)","by mail-ej1-f43.google.com with SMTP id\n a640c23a62f3a-b8f9568e074so468427966b.0\n for ; Sat, 11 Apr 2026 01:24:23 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1775895863;\n bh=bqoQbqPELWRk5acf+ZyoEUs3D/b4C2lVsVH6ctZMC9Q=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=II3SqzEvF+aEL6T1Ktmj0vBQS9DSc2uPxqNvuP8+603V6vWSyr6/diOddLJiJrIs1\n oo12F27qxFcQjira7eoMCf4GI1T26cnuxkW2YmwWeBe8IqYwrQB4WDtaGrurozPIkt\n fssKMZcYE2OigchYXFD5BDvJjL/hSm8JSSv8WWaeBrJMqMffQV+rQP6ePE0CEq7nvz\n 1aeP7YDa6GGsStwwkYgoPMsbEi976m7PcwUUEujZ2seM8JZrYgNXEq1RC9lCfraz3q\n XslLeKfMHcHZUPCDNZ56R51RQK2+YlQai2tUjoS5XHOIi788IpCbTsTLRjr2ZxQ3T8\n 2l9VdXJRZtzHg==","X-Forwarded-Encrypted":"i=1;\n AJvYcCUaJdgwdn4UCuKh03tn+BAMJ7MO6D7k3SFrGZtrSMIQUDS+9BpscDKD6dMq1z2wQZQeTqg1clmgxrff@nongnu.org","X-Gm-Message-State":"AOJu0Yz3N7OE+mPwYKCbI7d+Plb23rcM7Zsie4jsIwbJ/0GI7fTXwZ1u\n 9tnaVdOG9+adfY9Bt2pih3jjeNxYLhrICWPiKfyLltgx0XPCoabKMmEFtlo3ijB3+9Jqo2Jkc15\n KVpZYSKlusS9MnLyQTcQiDYlqJtOAkg4=","X-Received":"by 2002:a17:906:2092:b0:b9d:705e:1dae with SMTP id\n a640c23a62f3a-b9d72777e58mr214554466b.45.1775895861761; Sat, 11 Apr 2026\n 01:24:21 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n \n ","In-Reply-To":"\n ","From":"Huacai Chen ","Date":"Sat, 11 Apr 2026 16:24:28 +0800","X-Gmail-Original-Message-ID":"\n ","X-Gm-Features":"AQROBzDBFkqm0mDiVV5S0T1ys9AKylY71_Id4V7oF-ydWReoS3obfjTdvX-r68k","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Gyorgy Tamasi ","Cc":"gaosong ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Peter Maydell ,\n Richard Henderson ,\n bibo mao , xianglai li ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=172.105.4.254;\n envelope-from=chenhuacai@kernel.org;\n helo=tor.source.kernel.org","X-Spam_score_int":"-25","X-Spam_score":"-2.6","X-Spam_bar":"--","X-Spam_report":"(-2.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.54,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3676131,"web_url":"http://patchwork.ozlabs.org/comment/3676131/","msgid":"","list_archive_url":null,"date":"2026-04-11T10:39:10","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":93091,"url":"http://patchwork.ozlabs.org/api/people/93091/","name":"Gyorgy Tamasi","email":"gyorgy.tamasi@gmail.com"},"content":"> > This changeset was the last mod of syscall_defs.h - but it still\n> > incorrectly modifies the condition of struct target_stat64 usage:\n> > (~ \"Add Loongarch64 old ABI support\")\n> > https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n> > (line 2006)\n> > -----\n> > -#if !defined(TARGET_RISCV64)\n> > +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n> Huacai\n\nBut here the added \"|| defined(TARGET_LOONGARCH64)\" part doesn't fix\nthat affected bug similar to RISCV[32] vs. RISCV64...you need \"&&\n!defined(TARGET_LOONGARCH64)\" here to create an effect for\nTARGET_LOONGARCH64 similar to the proper solution for TARGET_RISCV64\n(~ disable the use of this struct target_stat64 with 32bit sec/nsec\nfields for a glibc environment where 64bit sec/nsecs are used - the\ndefault struct target_stat is perfect for these 64bit envs, do not let\nTARGET_HAS_STRUCT_STAT64 to be defined). [This 2nd embedded \"||\ndefined(TARGET_LOONGARCH64)\" within an other encapsulating \"||\ndefined(TARGET_LOONGARCH64)\" #elif-section is effectively a no-op here\n(the 2nd is always true, if the encapsulating 1st was true)...it does\nnot effectively change the behaviour of its conditional\ncode-fragment-body in the actual context...comparing to the original\n\"#if !defined(TARGET_RISCV64)\" full-line.]\n\nHow the contexts of LoongArch64 ABI1.0 vs. ABI2.0 are linked to this\nissue (related to an optional code-path in qemu/linux-user/syscall.c)?\nThe answer:\nThe existence of this bug does not directly depend on or linked to any\ndifference of core features of LA64's ABI1.0 vs. ABI2.0.\nThe difference in behaviour of ABI1.0 and ABI2.0 environments related\nto this qemu-code-part here strictly depends on the behaviour of\nspecific glibc versions used by those LA64 ABI1.0 and ABI2.0\nenvironments.\n\nIn the ABI1.0 env of glibc-2.28-7cdc44d5a1 used by Loongson's gcc 8.3\nrc1.6 a stat-like call (filling up a struct stat instance) IS NOT\nalways routed via the statx syscall, newfstatat can be used\ninstead!...and the processing of this newfstatat triggers the usage of\nthe problematic code-path in qemu/linux-user/syscall.c having this\nbug, related to the host_to_target_stat64() function, where this code\nfragment prefers to use struct target_stat64 (instead of struct\ntarget_stat), if its use is enabled by\ndefined(TARGET_HAS_STRUCT_STAT64):\n(~ around line 7975 in the 10.2.2 source)\n#if defined(TARGET_HAS_STRUCT_STAT64)\n struct target_stat64 *target_st;\n#else\n struct target_stat *target_st;\n#endif\n\nWhile in the ABI2.0 env of glibc of this gcc\nhttps://github.com/loongson/build-tools/releases/download/2025.08.08/x86_64-cross-tools-loongarch64-binutils_2.45-gcc_15.1.0-glibc_2.42.tar.xz\nfrom https://github.com/loongson/build-tools (glibc:\nhttps://ftp.gnu.org/gnu/glibc/glibc-2.42.tar.xz) ALL stat-like calls\nARE ROUTED via the statx syscall, so the problematic code path of\nhost_to_target_stat64() IS NOT used/triggered at all (and processing\npath of the statx syscall in linux-user/syscall.c is correct). This\nbehaviour of glibc-2.42 can be determined by these definitions in\nglibc-2.42/sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h:\n-----\n/* To avoid the messy usage of the fstat, newfstatat, and statx system calls, we\nonly use statx. */\n#undef __NR_fstat\n#undef __NR_newfstatat\n-----\n\n-tgy\n\nOn Sat, Apr 11, 2026 at 10:24 AM Huacai Chen wrote:\n>\n> On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi wrote:\n> >\n> > Hi,\n> >\n> > Thanks for the link of this separate Loongson-maintained 9.2-tcg-old\n> > branch - intended for use specifically with ABI 1.0 code.\n> >\n> > This separate branch still contains the same bug (in the context of\n> > the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\n> > fstatat syscall can be used by glibc, and it can trigger the usage of\n> > the related erroneous data-conversion workflow based on struct\n> > target_stat64 with 4byte sec/nsec fields):\n> >\n> > This changeset was the last mod of syscall_defs.h - but it still\n> > incorrectly modifies the condition of struct target_stat64 usage:\n> > (~ \"Add Loongarch64 old ABI support\")\n> > https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n> > (line 2006)\n> > -----\n> > -#if !defined(TARGET_RISCV64)\n> > +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n>\n> Huacai\n>\n> > -----\n> >\n> > This is the broader context in this 9.2-tcg-old original version:\n> > Here the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\n> > no-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\n> > is true/false.\n> > -----\n> > #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n> > || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n> > defined(TARGET_LOONGARCH64)\n> > /* These are the asm-generic versions of the stat and stat64 structures */\n> >\n> > #define TARGET_STAT_HAVE_NSEC\n> > struct target_stat {\n> > ...\n> > };\n> >\n> > #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> > #define TARGET_HAS_STRUCT_STAT64\n> > struct target_stat64 {\n> > ...\n> > };\n> > #endif\n> >\n> > #elif defined(TARGET_HPPA)\n> > -----\n> >\n> > The correct fix is the same here (~ disable the use of this struct\n> > target_stat64 - instead of explicitly enabling it for\n> > TARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n> > -----\n> > ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n> > --- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n> > +++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n> > @@ -2003,7 +2003,7 @@\n> > abi_uint __unused5;\n> > };\n> >\n> > -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> > +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n> > #define TARGET_HAS_STRUCT_STAT64\n> > struct target_stat64 {\n> > abi_ullong st_dev;\n> > -----\n> >\n> > The same test-scenario of\n> > https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n> > [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\n> > toolset] to show exactly the same bad & good test results - without &\n> > with this mod.\n> >\n> > Just a personal experience based side-note on ABI1.0 compatibility\n> > with mainline qemu (~10.2.2):\n> > I'm working on porting a quite large code-base (a commercial OCR &\n> > document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\n> > I'm trying to check correctness of my actual builds using the\n> > regression-test package of this codebase. It runs quite complex\n> > workflows of general CLI code. I accept that this is not a\n> > comprehensive test with all of the edge cases or touching every\n> > special areas (like signal handling) of compatibility of ABI1.0 and\n> > mainline qemu, but...the ABI1.0 version of this test-code seems to be\n> > able to run with mainline qemu-user 10.2.2.\n> >\n> > Best regards,\n> > -tgy\n> >\n> > On Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n> > >\n> > > 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n> > > > Tested-by: Gyorgy Tamasi \n> > > >\n> > > > Additional independent testing (bug + fix cases) is documented here -\n> > > > see comments by sourav/@kishu279:\n> > > > https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> > >\n> > > Hi.\n> > > Please note that QEMU is not compatible with ABI 1.0.\n> > >\n> > > If you absolutely must use ABI 1.0, the branch below is the version we use.\n> > > https://github.com/loongson/qemu/commits/9.2-tcg-old/\n> > >\n> > > However, this branch is quite far from the mainline.\n> > > The QEMU mainline follows the kernel mainline, and\n> > > I believe this is the case for other architectures as well.\n> > >\n> > > Thanks.\n> > > Song Gao\n> > > > On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n> > > > wrote:\n> > > >> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n> > > >>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n> > > >>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n> > > >>> target_stat64 for data-transfer, since this struct target_stat64 is\n> > > >>> defined for 32bit environments with its int-sized (4byte) st_*time\n> > > >>> sec/nsec components.\n> > > >>> The user side compiler headers of the LoongArch64 env uses long-sized\n> > > >>> (8byte) st_*time sec/nsec components.\n> > > >>>\n> > > >>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n> > > >>> code does not use struct target_stat64 in 64bit RISCV env, when both\n> > > >>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n> > > >>>\n> > > >>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n> > > >>> fstatat syscall with this struct target_stat64, if its usage is\n> > > >>> enabled.\n> > > >>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n> > > >>> problematic struct target_stat64 is not used, struct statx is correct\n> > > >>> in the LoongArch64 env.)\n> > > >>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> > > >>>\n> > > >>> Signed-off-by: Gyorgy Tamasi \n> > > >>> ---\n> > > >>> linux-user/syscall_defs.h | 2 +-\n> > > >>> 1 file changed, 1 insertion(+), 1 deletion(-)\n> > > >>>\n> > > >> Reviewed-by: Pierrick Bouvier \n> > >","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=SY1+BSpW;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4ft9DG5Tdnz1y2d\n\tfor ; Sat, 11 Apr 2026 20:40:12 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wBVkQ-0006yx-6D; Sat, 11 Apr 2026 06:39:30 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wBVkN-0006ym-6t\n for qemu-devel@nongnu.org; Sat, 11 Apr 2026 06:39:27 -0400","from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wBVkK-0000EI-Ea\n for qemu-devel@nongnu.org; Sat, 11 Apr 2026 06:39:26 -0400","by mail-lj1-x22b.google.com with SMTP id\n 38308e7fff4ca-38df1889fb9so30709921fa.1\n for ; Sat, 11 Apr 2026 03:39:23 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1775903961; cv=none;\n d=google.com; s=arc-20240605;\n b=FwYH2NyY96sYgDA19ooOqQPlaK9q3SyB5VJ1OjcGpH4/qNwYp+s9sF1aZ+o8inRaR4\n ToRS+Kei+5bz6rDc0hwlD0n+MOh+HHApvr9ROVn+s5222uLchbZsQvJ6KM4UFSlTidyi\n WKcjnDXlBQmicOD5s3OuACtL3z/xPAUp99JeOOyJTvI0jCCWPF6aCUsX0Tc59gS2O8r/\n U/OgjsLLmOLE9BZdpbl95IPGGE+BfzzDQwOVZMp58vFzxhMYkW3S4jRxs9wEhYeDUCUt\n txKbr2lGj2CU6PAGwfXVPesDjPOyTQU11V5hN50iMu5p20wCVuvMi587rw4o47jFHZkk\n 9JWw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=TaDK7ZIqg9WV8Y0/xPGkoRXmyNtXi2ntIED7sMJIEaY=;\n fh=eWx0tyDlnMUvPzdJnhSVUnpoEQSSSeLtEb7cjgKksBc=;\n b=BzngAr6k2QwuV7mKfu7y3poqNaNuSgjIYTnVrRJgtHMROdjwct4Y7HcngPHf6AOqfi\n RD7nlcatXsLgqMjZ1aZzGYOMFbStvYSMKl7kwC4h8f6t6b5/RWaW1FJnY7khW0mzm1na\n MJzTHMIoGxKpuiDeekuNc5NBl1+o3PgQTzIMdbiFekGO8rALyJ0h85pxc5WX/ocV4RfV\n xdou+fYMiaEE1g4VSS744N5ijiho4HyKKBOdTetdzW84zcSYQnKuiO5c3ktY4/Bjpn3T\n gSKz6e0zPNUMR8NfmRTiCebGmtjL4Rz4Q2nIR/ugWr/Q9AT7ZXK1X2vuS+dUy3G7/MPO\n bokA==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775903961; x=1776508761; darn=nongnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=TaDK7ZIqg9WV8Y0/xPGkoRXmyNtXi2ntIED7sMJIEaY=;\n b=SY1+BSpWIaPlMIfa+f4rxvECcX2a1i6CxBU6qKqTAK9nlEdP1pvK26nFid/K2PirDA\n SlRE+CYCNt0KdU8w1WygSpaKfCM9vjMATybVzJOtmMJM/t3vDJ6U0NMv6altgz2SyJVy\n 3YgmOou8D4iwoWqq2kWWnaFXLepkwGAmn0YXVWQwyTK9lKd3zFDu+AGnfHLS6itOAE4u\n M8LNeB+d2+ysWPUS/nxQ+nvINOusOlOWNmFWHCGSPmaNu4xfYjk+vQhrBtf380sOjHXK\n 0b94HibM9wUmPUQHlJpcMqhKgia/HMKdyma06UvpzX/g4kydB1TGpk2b+HzUElYj+K7K\n 8WKQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775903961; x=1776508761;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=TaDK7ZIqg9WV8Y0/xPGkoRXmyNtXi2ntIED7sMJIEaY=;\n b=nsoNr9HaZMpS/KlieYONZU6SMe6jf5oYzSHkFRYu5qlKpkZozONa4FbyeizTY9mxWH\n F6AlbuSv/mSntf4pbhc4u2IkK+OAUfnMPpXHaQuAhDg6nG7gFDC5TuPFLYMH/Rv2MmGt\n bxLNCiD3MonGTFND6Dd6GuYVva5Nr2XPEmFgECMk4h7n53KL+7f4dV/T7zYDUPPgNWQ0\n EbhS1iGNUDrNFcLWSwSWKFniQHE6AwOWbWwDLXqsMFln/Uk8ffjrGLXmRDsvggp9C+NF\n CJ7kCtk/+gM+/+JtlWb4RxMozYPtKFW2Pk3urLq1RXgqgwEiNhjZjGVgEe6UsYnh48xn\n eBDQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCU8SZ1OzPdZVh66AvzP1+v1eAH3PEJ7KRiVP5ZVGElq6rtkzE4zJJX4wIzhy30Y+MoS9s7O27uUjhhX@nongnu.org","X-Gm-Message-State":"AOJu0Yztc8NLfuRpgttAabGY9djMXreInyIwo5Arhc1sn55k6s/8jgJR\n zlQ8kD/drbp+f5OxU8yE582btlVrgcDN4uHS5eXGuIaJtJwP5riqNpQMPIupeW6N7nX1dLeFRBR\n 12dTRW0+VzNIDaBuEjGaDa+gfIuNcWE4=","X-Gm-Gg":"AeBDietk7sResGG7Gxv0UdJnL5wx6zEXmBAjYp+w0h5OgnM3xHyEhc2nbtseKl1neB9\n omZi+hdC7vSA5dmoCxiITDQNWh/2baDLrza6blMGCbB53dX4ParQgWymsf/lrtm5oM21vsDcmrO\n l27ALH1z9ikj2eobgtNZd4YlQER5Hth0S0Zo83hySte8UG+BtT3qtQtR1IEjwTCUU/6nPNp9sSn\n XzZezMXioMRsTpEG89J8wi+nn0ifquRc0IHYIYz9XUrd7pVRZSKYltNkGo7djUJAA0BMdhnASch\n G9hYLKL3tKtTwclXK4EI7vrsAC/C/aHSgA80l6D9","X-Received":"by 2002:a05:6512:3c9e:b0:5a1:3207:694c with SMTP id\n 2adb3069b0e04-5a3efd8a12emr2078265e87.29.1775903960499; Sat, 11 Apr 2026\n 03:39:20 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Gyorgy Tamasi ","Date":"Sat, 11 Apr 2026 12:39:10 +0200","X-Gm-Features":"AQROBzCw2agMgCfcliBqQ0qyUc9YLpcazzcEOJF5Qna3QU2W4oV7QmdPZf14mzM","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Huacai Chen ","Cc":"gaosong ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Peter Maydell ,\n Richard Henderson ,\n bibo mao , xianglai li ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=2a00:1450:4864:20::22b;\n envelope-from=gyorgy.tamasi@gmail.com; helo=mail-lj1-x22b.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3676419,"web_url":"http://patchwork.ozlabs.org/comment/3676419/","msgid":"<73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>","list_archive_url":null,"date":"2026-04-13T03:05:47","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":82024,"url":"http://patchwork.ozlabs.org/api/people/82024/","name":"Song Gao","email":"gaosong@loongson.cn"},"content":"在 2026/4/11 下午6:39, Gyorgy Tamasi 写道:\n>>> This changeset was the last mod of syscall_defs.h - but it still\n>>> incorrectly modifies the condition of struct target_stat64 usage:\n>>> (~ \"Add Loongarch64 old ABI support\")\n>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n>>> (line 2006)\n>>> -----\n>>> -#if !defined(TARGET_RISCV64)\n>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n>> Huacai\n> But here the added \"|| defined(TARGET_LOONGARCH64)\" part doesn't fix\n> that affected bug similar to RISCV[32] vs. RISCV64...you need \"&&\n> !defined(TARGET_LOONGARCH64)\" here to create an effect for\n> TARGET_LOONGARCH64 similar to the proper solution for TARGET_RISCV64\n> (~ disable the use of this struct target_stat64 with 32bit sec/nsec\n> fields for a glibc environment where 64bit sec/nsecs are used - the\n> default struct target_stat is perfect for these 64bit envs, do not let\n> TARGET_HAS_STRUCT_STAT64 to be defined). [This 2nd embedded \"||\n> defined(TARGET_LOONGARCH64)\" within an other encapsulating \"||\n> defined(TARGET_LOONGARCH64)\" #elif-section is effectively a no-op here\n> (the 2nd is always true, if the encapsulating 1st was true)...it does\n> not effectively change the behaviour of its conditional\n> code-fragment-body in the actual context...comparing to the original\n> \"#if !defined(TARGET_RISCV64)\" full-line.]\n>\n> How the contexts of LoongArch64 ABI1.0 vs. ABI2.0 are linked to this\n> issue (related to an optional code-path in qemu/linux-user/syscall.c)?\n> The answer:\n> The existence of this bug does not directly depend on or linked to any\n> difference of core features of LA64's ABI1.0 vs. ABI2.0.\n> The difference in behaviour of ABI1.0 and ABI2.0 environments related\n> to this qemu-code-part here strictly depends on the behaviour of\n> specific glibc versions used by those LA64 ABI1.0 and ABI2.0\n> environments.\n>\n> In the ABI1.0 env of glibc-2.28-7cdc44d5a1 used by Loongson's gcc 8.3\n> rc1.6 a stat-like call (filling up a struct stat instance) IS NOT\n> always routed via the statx syscall, newfstatat can be used\n> instead!...and the processing of this newfstatat triggers the usage of\n> the problematic code-path in qemu/linux-user/syscall.c having this\n> bug, related to the host_to_target_stat64() function, where this code\n> fragment prefers to use struct target_stat64 (instead of struct\n> target_stat), if its use is enabled by\n> defined(TARGET_HAS_STRUCT_STAT64):\n> (~ around line 7975 in the 10.2.2 source)\n> #if defined(TARGET_HAS_STRUCT_STAT64)\n> struct target_stat64 *target_st;\n> #else\n> struct target_stat *target_st;\n> #endif\n>\n> While in the ABI2.0 env of glibc of this gcc\n> https://github.com/loongson/build-tools/releases/download/2025.08.08/x86_64-cross-tools-loongarch64-binutils_2.45-gcc_15.1.0-glibc_2.42.tar.xz\n> from https://github.com/loongson/build-tools (glibc:\n> https://ftp.gnu.org/gnu/glibc/glibc-2.42.tar.xz) ALL stat-like calls\n> ARE ROUTED via the statx syscall, so the problematic code path of\n> host_to_target_stat64() IS NOT used/triggered at all (and processing\n> path of the statx syscall in linux-user/syscall.c is correct). This\n> behaviour of glibc-2.42 can be determined by these definitions in\n> glibc-2.42/sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h:\n> -----\n> /* To avoid the messy usage of the fstat, newfstatat, and statx system calls, we\n> only use statx. */\n> #undef __NR_fstat\n> #undef __NR_newfstatat\n> -----\n>\n> -tgy\nHi,\n\nThank you for your explanation.\n\nI confirm that the same issue exists in the 9.2-tcg-old branch, and you have clearly identified the root cause of the problem.\nThere is no doubt that the patch itself is fine, but what confuses me is that you attempted to run (ABI 1.0.0) using QEMU (ABI 2.0),\nwhich led to the misconception that QEMU (2.0) is compatible with 1.0, when in fact QEMU has never been compatible with 1.0.\nAs far as I understand, the differences between the ABI 2.0 and ABI 1.0 environments should be quite significant.\n\nTherefore, I am unsure whether we should accept this patch.\nShould we submit this patch to the 9.2-tcg-0ld branch?\nOr should you consider discontinuing support for ABI 1.0? To my knowledge, ABI 2.0 has now become the mainstream standard.\n\nThanks.\nSong Gao\n\n>\n> On Sat, Apr 11, 2026 at 10:24 AM Huacai Chen wrote:\n>> On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi wrote:\n>>> Hi,\n>>>\n>>> Thanks for the link of this separate Loongson-maintained 9.2-tcg-old\n>>> branch - intended for use specifically with ABI 1.0 code.\n>>>\n>>> This separate branch still contains the same bug (in the context of\n>>> the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\n>>> fstatat syscall can be used by glibc, and it can trigger the usage of\n>>> the related erroneous data-conversion workflow based on struct\n>>> target_stat64 with 4byte sec/nsec fields):\n>>>\n>>> This changeset was the last mod of syscall_defs.h - but it still\n>>> incorrectly modifies the condition of struct target_stat64 usage:\n>>> (~ \"Add Loongarch64 old ABI support\")\n>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n>>> (line 2006)\n>>> -----\n>>> -#if !defined(TARGET_RISCV64)\n>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n>>\n>> Huacai\n>>\n>>> -----\n>>>\n>>> This is the broader context in this 9.2-tcg-old original version:\n>>> Here the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\n>>> no-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\n>>> is true/false.\n>>> -----\n>>> #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n>>> || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n>>> defined(TARGET_LOONGARCH64)\n>>> /* These are the asm-generic versions of the stat and stat64 structures */\n>>>\n>>> #define TARGET_STAT_HAVE_NSEC\n>>> struct target_stat {\n>>> ...\n>>> };\n>>>\n>>> #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>> #define TARGET_HAS_STRUCT_STAT64\n>>> struct target_stat64 {\n>>> ...\n>>> };\n>>> #endif\n>>>\n>>> #elif defined(TARGET_HPPA)\n>>> -----\n>>>\n>>> The correct fix is the same here (~ disable the use of this struct\n>>> target_stat64 - instead of explicitly enabling it for\n>>> TARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n>>> -----\n>>> ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n>>> --- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n>>> +++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n>>> @@ -2003,7 +2003,7 @@\n>>> abi_uint __unused5;\n>>> };\n>>>\n>>> -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>> +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n>>> #define TARGET_HAS_STRUCT_STAT64\n>>> struct target_stat64 {\n>>> abi_ullong st_dev;\n>>> -----\n>>>\n>>> The same test-scenario of\n>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n>>> [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\n>>> toolset] to show exactly the same bad & good test results - without &\n>>> with this mod.\n>>>\n>>> Just a personal experience based side-note on ABI1.0 compatibility\n>>> with mainline qemu (~10.2.2):\n>>> I'm working on porting a quite large code-base (a commercial OCR &\n>>> document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\n>>> I'm trying to check correctness of my actual builds using the\n>>> regression-test package of this codebase. It runs quite complex\n>>> workflows of general CLI code. I accept that this is not a\n>>> comprehensive test with all of the edge cases or touching every\n>>> special areas (like signal handling) of compatibility of ABI1.0 and\n>>> mainline qemu, but...the ABI1.0 version of this test-code seems to be\n>>> able to run with mainline qemu-user 10.2.2.\n>>>\n>>> Best regards,\n>>> -tgy\n>>>\n>>> On Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n>>>> 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n>>>>> Tested-by: Gyorgy Tamasi \n>>>>>\n>>>>> Additional independent testing (bug + fix cases) is documented here -\n>>>>> see comments by sourav/@kishu279:\n>>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>>>> Hi.\n>>>> Please note that QEMU is not compatible with ABI 1.0.\n>>>>\n>>>> If you absolutely must use ABI 1.0, the branch below is the version we use.\n>>>> https://github.com/loongson/qemu/commits/9.2-tcg-old/\n>>>>\n>>>> However, this branch is quite far from the mainline.\n>>>> The QEMU mainline follows the kernel mainline, and\n>>>> I believe this is the case for other architectures as well.\n>>>>\n>>>> Thanks.\n>>>> Song Gao\n>>>>> On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n>>>>> wrote:\n>>>>>> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n>>>>>>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n>>>>>>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n>>>>>>> target_stat64 for data-transfer, since this struct target_stat64 is\n>>>>>>> defined for 32bit environments with its int-sized (4byte) st_*time\n>>>>>>> sec/nsec components.\n>>>>>>> The user side compiler headers of the LoongArch64 env uses long-sized\n>>>>>>> (8byte) st_*time sec/nsec components.\n>>>>>>>\n>>>>>>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n>>>>>>> code does not use struct target_stat64 in 64bit RISCV env, when both\n>>>>>>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n>>>>>>>\n>>>>>>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n>>>>>>> fstatat syscall with this struct target_stat64, if its usage is\n>>>>>>> enabled.\n>>>>>>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n>>>>>>> problematic struct target_stat64 is not used, struct statx is correct\n>>>>>>> in the LoongArch64 env.)\n>>>>>>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>>>>>>>\n>>>>>>> Signed-off-by: Gyorgy Tamasi \n>>>>>>> ---\n>>>>>>> linux-user/syscall_defs.h | 2 +-\n>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>>>>>>\n>>>>>> Reviewed-by: Pierrick Bouvier ","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fvC2y22fFz1yGC\n\tfor ; Mon, 13 Apr 2026 13:05:44 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wC7bj-0001Q1-Mc; Sun, 12 Apr 2026 23:05:03 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wC7bf-0001Pf-5n\n for qemu-devel@nongnu.org; Sun, 12 Apr 2026 23:04:59 -0400","from mail.loongson.cn ([114.242.206.163])\n by eggs.gnu.org with esmtp (Exim 4.90_1)\n (envelope-from ) id 1wC7bb-0008Ak-93\n for qemu-devel@nongnu.org; Sun, 12 Apr 2026 23:04:58 -0400","from loongson.cn (unknown [10.20.42.239])\n by gateway (Coremail) with SMTP id _____8BxFMFBXdxpk50kAA--.54176S3;\n Mon, 13 Apr 2026 11:04:33 +0800 (CST)","from [10.20.42.239] (unknown [10.20.42.239])\n by front1 (Coremail) with SMTP id qMiowJCxPMI6XdxpsNVrAA--.6719S3;\n Mon, 13 Apr 2026 11:04:29 +0800 (CST)"],"Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Gyorgy Tamasi ,\n Huacai Chen ","Cc":"Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Peter Maydell ,\n Richard Henderson ,\n bibo mao , xianglai li ","References":"\n \n \n \n \n \n \n ","From":"gaosong ","Message-ID":"<73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>","Date":"Mon, 13 Apr 2026 11:05:47 +0800","User-Agent":"Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101\n Thunderbird/68.7.0","MIME-Version":"1.0","In-Reply-To":"\n ","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","X-CM-TRANSID":"qMiowJCxPMI6XdxpsNVrAA--.6719S3","X-CM-SenderInfo":"5jdr20tqj6z05rqj20fqof0/","X-Coremail-Antispam":"1Uk129KBj93XoW3uFWUAw15Xr13XF1xWF48AFc_yoWDtF4DpF\n yxGF47KF4UXrWfCwnag3WUZFyFvw1fJryUWFy0qr40yas0qr1xtF4jgrW3CF9Fv34v934j\n vrWjk3sxuF4UZagCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa\n sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU\n 0xBIdaVrnRJUUUv2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2\n IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v\n e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI\n 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK\n xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx\n 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv\n 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07\n AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02\n F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GF\n ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj\n xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r\n 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8j-\n e5UUUUU==","Received-SPF":"pass client-ip=114.242.206.163;\n envelope-from=gaosong@loongson.cn;\n helo=mail.loongson.cn","X-Spam_score_int":"-49","X-Spam_score":"-5.0","X-Spam_bar":"-----","X-Spam_report":"(-5.0 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-3.135,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3677750,"web_url":"http://patchwork.ozlabs.org/comment/3677750/","msgid":"","list_archive_url":null,"date":"2026-04-15T16:06:44","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":93091,"url":"http://patchwork.ozlabs.org/api/people/93091/","name":"Gyorgy Tamasi","email":"gyorgy.tamasi@gmail.com"},"content":"Hi,\n\nThis is a very simple change within a broader and more complex logical\ncontext. It has an important property: it targets a single specific\nQEMU configuration (LOONGARCH64) and has no possible side effects for\nother configurations. Additionally, it can only have a positive effect\nin any context (in any QEMU fork) when the modified code is\nexecuted—even in non-standard or unexpected scenarios, such as\nattempting to run an ABI 1.0 binary using a qemu-user-loongarch64\nbuild intended for ABI 2.0. In such cases, if the limited (non-ABI\n2.0–specific) feature set of the ABI 1.0 application happens to allow\nexecution, this change still behaves safely. In this sense, it follows\na fundamental principle of software bug fixing (and medicine): primum\nnon nocere (“first, do no harm”). 🙂\n\nI understand that we are currently in the middle of an important\ntransition period, during which even traditionally “Old World” (ABI\n1.0–dependent) LoongArch64 Linux distributions are releasing their\n“New World” (ABI 2.0–specific) versions.\n\nI do not feel qualified to estimate the duration of the next phase of\nthis transition, namely the replacement of ABI 1.0 OS installations\nwith ABI 2.0 versions in the end-user base. If a company plans to\nrelease something for LoongArch64 now, and its goal is to make it\navailable to as many users as possible, building for ABI 2.0—and\noptionally also for ABI 1.0—may still be a reasonable choice (provided\na sufficiently large number of users are still on ABI 1.0 systems\nbefore they upgrade).\n\nMy (admittedly very specific) personal perspective: I do not yet have\naccess to real LoongArch64 hardware, so I have been testing both ABI\n2.0 and ABI 1.0 LA64 binaries using different qemu-user versions (even\nif this is not a typical use case). Since I have already applied this\nmodification in my own qemu-user builds, the issue no longer affects\nme. Therefore, I can accept that this fix may not be integrated into\nthe official QEMU branches (given that it concerns the now phasing-out\nABI 1.0). The decision is beyond my scope.\n\nBest regards,\n-tgy\n\n\nOn Mon, Apr 13, 2026 at 5:04 AM gaosong wrote:\n>\n> 在 2026/4/11 下午6:39, Gyorgy Tamasi 写道:\n> >>> This changeset was the last mod of syscall_defs.h - but it still\n> >>> incorrectly modifies the condition of struct target_stat64 usage:\n> >>> (~ \"Add Loongarch64 old ABI support\")\n> >>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n> >>> (line 2006)\n> >>> -----\n> >>> -#if !defined(TARGET_RISCV64)\n> >>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n> >> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n> >> Huacai\n> > But here the added \"|| defined(TARGET_LOONGARCH64)\" part doesn't fix\n> > that affected bug similar to RISCV[32] vs. RISCV64...you need \"&&\n> > !defined(TARGET_LOONGARCH64)\" here to create an effect for\n> > TARGET_LOONGARCH64 similar to the proper solution for TARGET_RISCV64\n> > (~ disable the use of this struct target_stat64 with 32bit sec/nsec\n> > fields for a glibc environment where 64bit sec/nsecs are used - the\n> > default struct target_stat is perfect for these 64bit envs, do not let\n> > TARGET_HAS_STRUCT_STAT64 to be defined). [This 2nd embedded \"||\n> > defined(TARGET_LOONGARCH64)\" within an other encapsulating \"||\n> > defined(TARGET_LOONGARCH64)\" #elif-section is effectively a no-op here\n> > (the 2nd is always true, if the encapsulating 1st was true)...it does\n> > not effectively change the behaviour of its conditional\n> > code-fragment-body in the actual context...comparing to the original\n> > \"#if !defined(TARGET_RISCV64)\" full-line.]\n> >\n> > How the contexts of LoongArch64 ABI1.0 vs. ABI2.0 are linked to this\n> > issue (related to an optional code-path in qemu/linux-user/syscall.c)?\n> > The answer:\n> > The existence of this bug does not directly depend on or linked to any\n> > difference of core features of LA64's ABI1.0 vs. ABI2.0.\n> > The difference in behaviour of ABI1.0 and ABI2.0 environments related\n> > to this qemu-code-part here strictly depends on the behaviour of\n> > specific glibc versions used by those LA64 ABI1.0 and ABI2.0\n> > environments.\n> >\n> > In the ABI1.0 env of glibc-2.28-7cdc44d5a1 used by Loongson's gcc 8.3\n> > rc1.6 a stat-like call (filling up a struct stat instance) IS NOT\n> > always routed via the statx syscall, newfstatat can be used\n> > instead!...and the processing of this newfstatat triggers the usage of\n> > the problematic code-path in qemu/linux-user/syscall.c having this\n> > bug, related to the host_to_target_stat64() function, where this code\n> > fragment prefers to use struct target_stat64 (instead of struct\n> > target_stat), if its use is enabled by\n> > defined(TARGET_HAS_STRUCT_STAT64):\n> > (~ around line 7975 in the 10.2.2 source)\n> > #if defined(TARGET_HAS_STRUCT_STAT64)\n> > struct target_stat64 *target_st;\n> > #else\n> > struct target_stat *target_st;\n> > #endif\n> >\n> > While in the ABI2.0 env of glibc of this gcc\n> > https://github.com/loongson/build-tools/releases/download/2025.08.08/x86_64-cross-tools-loongarch64-binutils_2.45-gcc_15.1.0-glibc_2.42.tar.xz\n> > from https://github.com/loongson/build-tools (glibc:\n> > https://ftp.gnu.org/gnu/glibc/glibc-2.42.tar.xz) ALL stat-like calls\n> > ARE ROUTED via the statx syscall, so the problematic code path of\n> > host_to_target_stat64() IS NOT used/triggered at all (and processing\n> > path of the statx syscall in linux-user/syscall.c is correct). This\n> > behaviour of glibc-2.42 can be determined by these definitions in\n> > glibc-2.42/sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h:\n> > -----\n> > /* To avoid the messy usage of the fstat, newfstatat, and statx system calls, we\n> > only use statx. */\n> > #undef __NR_fstat\n> > #undef __NR_newfstatat\n> > -----\n> >\n> > -tgy\n> Hi,\n>\n> Thank you for your explanation.\n>\n> I confirm that the same issue exists in the 9.2-tcg-old branch, and you have clearly identified the root cause of the problem.\n> There is no doubt that the patch itself is fine, but what confuses me is that you attempted to run (ABI 1.0.0) using QEMU (ABI 2.0),\n> which led to the misconception that QEMU (2.0) is compatible with 1.0, when in fact QEMU has never been compatible with 1.0.\n> As far as I understand, the differences between the ABI 2.0 and ABI 1.0 environments should be quite significant.\n>\n> Therefore, I am unsure whether we should accept this patch.\n> Should we submit this patch to the 9.2-tcg-0ld branch?\n> Or should you consider discontinuing support for ABI 1.0? To my knowledge, ABI 2.0 has now become the mainstream standard.\n>\n> Thanks.\n> Song Gao\n>\n> >\n> > On Sat, Apr 11, 2026 at 10:24 AM Huacai Chen wrote:\n> >> On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi wrote:\n> >>> Hi,\n> >>>\n> >>> Thanks for the link of this separate Loongson-maintained 9.2-tcg-old\n> >>> branch - intended for use specifically with ABI 1.0 code.\n> >>>\n> >>> This separate branch still contains the same bug (in the context of\n> >>> the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\n> >>> fstatat syscall can be used by glibc, and it can trigger the usage of\n> >>> the related erroneous data-conversion workflow based on struct\n> >>> target_stat64 with 4byte sec/nsec fields):\n> >>>\n> >>> This changeset was the last mod of syscall_defs.h - but it still\n> >>> incorrectly modifies the condition of struct target_stat64 usage:\n> >>> (~ \"Add Loongarch64 old ABI support\")\n> >>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n> >>> (line 2006)\n> >>> -----\n> >>> -#if !defined(TARGET_RISCV64)\n> >>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n> >> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n> >>\n> >> Huacai\n> >>\n> >>> -----\n> >>>\n> >>> This is the broader context in this 9.2-tcg-old original version:\n> >>> Here the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\n> >>> no-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\n> >>> is true/false.\n> >>> -----\n> >>> #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n> >>> || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n> >>> defined(TARGET_LOONGARCH64)\n> >>> /* These are the asm-generic versions of the stat and stat64 structures */\n> >>>\n> >>> #define TARGET_STAT_HAVE_NSEC\n> >>> struct target_stat {\n> >>> ...\n> >>> };\n> >>>\n> >>> #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >>> #define TARGET_HAS_STRUCT_STAT64\n> >>> struct target_stat64 {\n> >>> ...\n> >>> };\n> >>> #endif\n> >>>\n> >>> #elif defined(TARGET_HPPA)\n> >>> -----\n> >>>\n> >>> The correct fix is the same here (~ disable the use of this struct\n> >>> target_stat64 - instead of explicitly enabling it for\n> >>> TARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n> >>> -----\n> >>> ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n> >>> --- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n> >>> +++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n> >>> @@ -2003,7 +2003,7 @@\n> >>> abi_uint __unused5;\n> >>> };\n> >>>\n> >>> -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >>> +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n> >>> #define TARGET_HAS_STRUCT_STAT64\n> >>> struct target_stat64 {\n> >>> abi_ullong st_dev;\n> >>> -----\n> >>>\n> >>> The same test-scenario of\n> >>> https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n> >>> [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\n> >>> toolset] to show exactly the same bad & good test results - without &\n> >>> with this mod.\n> >>>\n> >>> Just a personal experience based side-note on ABI1.0 compatibility\n> >>> with mainline qemu (~10.2.2):\n> >>> I'm working on porting a quite large code-base (a commercial OCR &\n> >>> document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\n> >>> I'm trying to check correctness of my actual builds using the\n> >>> regression-test package of this codebase. It runs quite complex\n> >>> workflows of general CLI code. I accept that this is not a\n> >>> comprehensive test with all of the edge cases or touching every\n> >>> special areas (like signal handling) of compatibility of ABI1.0 and\n> >>> mainline qemu, but...the ABI1.0 version of this test-code seems to be\n> >>> able to run with mainline qemu-user 10.2.2.\n> >>>\n> >>> Best regards,\n> >>> -tgy\n> >>>\n> >>> On Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n> >>>> 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n> >>>>> Tested-by: Gyorgy Tamasi \n> >>>>>\n> >>>>> Additional independent testing (bug + fix cases) is documented here -\n> >>>>> see comments by sourav/@kishu279:\n> >>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> >>>> Hi.\n> >>>> Please note that QEMU is not compatible with ABI 1.0.\n> >>>>\n> >>>> If you absolutely must use ABI 1.0, the branch below is the version we use.\n> >>>> https://github.com/loongson/qemu/commits/9.2-tcg-old/\n> >>>>\n> >>>> However, this branch is quite far from the mainline.\n> >>>> The QEMU mainline follows the kernel mainline, and\n> >>>> I believe this is the case for other architectures as well.\n> >>>>\n> >>>> Thanks.\n> >>>> Song Gao\n> >>>>> On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n> >>>>> wrote:\n> >>>>>> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n> >>>>>>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n> >>>>>>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n> >>>>>>> target_stat64 for data-transfer, since this struct target_stat64 is\n> >>>>>>> defined for 32bit environments with its int-sized (4byte) st_*time\n> >>>>>>> sec/nsec components.\n> >>>>>>> The user side compiler headers of the LoongArch64 env uses long-sized\n> >>>>>>> (8byte) st_*time sec/nsec components.\n> >>>>>>>\n> >>>>>>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n> >>>>>>> code does not use struct target_stat64 in 64bit RISCV env, when both\n> >>>>>>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n> >>>>>>>\n> >>>>>>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n> >>>>>>> fstatat syscall with this struct target_stat64, if its usage is\n> >>>>>>> enabled.\n> >>>>>>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n> >>>>>>> problematic struct target_stat64 is not used, struct statx is correct\n> >>>>>>> in the LoongArch64 env.)\n> >>>>>>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> >>>>>>>\n> >>>>>>> Signed-off-by: Gyorgy Tamasi \n> >>>>>>> ---\n> >>>>>>> linux-user/syscall_defs.h | 2 +-\n> >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n> >>>>>>>\n> >>>>>> Reviewed-by: Pierrick Bouvier \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=oJQs/sDf;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwmJ90M60z1yHc\n\tfor ; Thu, 16 Apr 2026 02:07:37 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wD2lg-0005c9-D4; Wed, 15 Apr 2026 12:07:11 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wD2lY-0005br-A6\n for qemu-devel@nongnu.org; Wed, 15 Apr 2026 12:07:00 -0400","from mail-lf1-x132.google.com ([2a00:1450:4864:20::132])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wD2lU-0007s4-SM\n for qemu-devel@nongnu.org; Wed, 15 Apr 2026 12:06:59 -0400","by mail-lf1-x132.google.com with SMTP id\n 2adb3069b0e04-59e4a04f059so6687262e87.2\n for ; Wed, 15 Apr 2026 09:06:55 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776269214; cv=none;\n d=google.com; s=arc-20240605;\n b=MIq5YgIMk99B1IUmHh0OrMskJOSm1woU7cxKRFE4xBwTYmxq1iYsk11RlkcgC0C7O0\n CJSUZFIB3di2jX8061pWN9BmrUzqjrUmjGSZlUWF37bl3nRFvx5JaaKClVatktUCurLK\n mODfDPnFaPV01fiHAB1C+f0gmeTowr/QHAwQBz/XiJ/DFYUGwrHDj54S1XLE53Cor001\n +aq/Ei1+7NB/fGVz+7X0bJH4GOIWhJlpuExObTd+VEFwermaVoT2xecc6cCUwg4uhCHm\n 1VUE1Vkg/7nOkEff5QWO+zM/ycmEFbifNN0h1twhoidBztwUJ1x6nBicTq3x2y+8VEff\n Eaig==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=82W50w1NovQ3iogFOyeKDY6MzG//aT9qGjZlXhruf34=;\n fh=eQ8gFmoiRTPJ7q6dt3ypbYMdb6M0NZFRnAZWQvy9k7w=;\n b=VJI4JT0PUzgr4L/QLfCRK0RF3FcbSg+l97vQzMX5kI8XgjZdTFMFl7EceWmZeiivSK\n ZAeFVLGuo7YmPc7FgSnLrAxrTeEiXtGavTs4K/G7xpHGvkJv+/kqgpEw+vChUhqCWUAp\n AHOcMcW0iu/3ejXhW3dwvMJu6LMMoj95kIZ558PIYgJWxXH2m1NxTRPmNoSJq0msNM82\n ZzF8iKT8Tb1RvVP91eFyQk+slidajUBVkqEN38tZ0C48fjW0upvw17iVHAJ1nkSVY+XC\n 8qnhzEydxndBuRjbCccu8FA2MrMR+24GQJqgtuKXS33Lj09VfXEnUQhS+2/W+3Z3LqlA\n e1zg==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776269214; x=1776874014; darn=nongnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=82W50w1NovQ3iogFOyeKDY6MzG//aT9qGjZlXhruf34=;\n b=oJQs/sDfHmRSmvRubV/JN+nOjP+0fg0SNRFjZlhBwLbtnAFh/J3hJkkbEO0gEDvO0C\n jePjz7Xi/zTGab9R71cuUCieItVDD0SqjUl2zXveEiIBhF2/jOw86C9hL2X6/DjYouMV\n qR4F+jTUaJ8UQlJKs6SfT3cX4Jb79fGjz6+g5snqM9Jqn9+buUzTfHUwVnEwygoIt+Ne\n qnKnt8T4cOtNcHIAWl4r5RIC0kTAsIu1KMfTF5whkxrvESVx0+HCOT8MXuSn0cS4USlM\n XVbWzUq4ZVeJdTeE+1jy+4WI4M4oW0c3cNzTkmP+H2lB14Z9/FM70U7IRTkRMLj0OCGG\n NTtQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776269214; x=1776874014;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=82W50w1NovQ3iogFOyeKDY6MzG//aT9qGjZlXhruf34=;\n b=E1H0I5CeTnjBPPYfceo7KobqP0DSQZgEOw4UqlwYX4I7+i0nSANLcPKx0gxKcxxXxW\n 9jMjp71e1Ue3h4n7OFaQuV+/nuCjmz4pCcryRE3whQwi+6RlkpIVyESFydTnX+SHrmtP\n Rv831UCVGrNXiS2t3G7lVX/g1F0EZBC31rri7C6u4i5siQyKlB3LuX6dwYJE6mwVVfT5\n BOkKT9M5LN1HfLmY01GBtI6zKjf3B1AK+Cx3v1iUp2YDCPEU/ERSUbGN4IfBwxCu0dyl\n htGenqMHjRhhPEN8UzR+CnCELObeyHkriT92Z50FltP2rI+UKXVetORfA9JTd7yU8YSG\n kJXg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ80e7eVw6pDwilXzzhFB09K+QK6xrZ6ZYqmFjlDF5jNMYJfsOTmcWCRtc4Lr9SWL/7FCOmC9nZu1V4/@nongnu.org","X-Gm-Message-State":"AOJu0YxhemnlOVU7aKBVXAv1VO50s4S8zbCtDhA8rhBZBEhI9tIkyiTQ\n pkv/e4J2L+Sy5FtAG9BMeEhTiglT7EicZHNClonEJnhgDIKjS0J+vS6BAOSAc4QPYXcwEy4BCbn\n IwHCr8TT1HwZBGzEW4AAp7ijs9INPKOs=","X-Gm-Gg":"AeBDieswJ/TqQLe3kQpFLkDOdJfgVNvGVVZWese00FVKcpMira3WyYVf/eLdSsxjNq1\n bmGAtN1gWo4UGRsJ6151+dJ2TamHhZXkOPUByC6lpFobjHdWfVsNmaiJur1UfQ42q/GvV73FQ56\n 96/ydUz6G99YgyGZ+PmZ79iqx1p95hrWE+P7S6pMQiW0FW2e9NH5c53bvuKHwABtE+1/syDZ0wb\n uDuxkv/5wHSikWU/t4yjncWR/ur46rqdhXiJO373WrykJWQZE97sjJPuE0In9rYSEwj8jpQrOzV\n eXk5xCxkBhBBck3nj0o6EQK+drJpT+DCMbSjz60/PbWzS/i0IqQ=","X-Received":"by 2002:a05:6512:1287:b0:5a3:d30b:958a with SMTP id\n 2adb3069b0e04-5a3efb8be95mr6928775e87.22.1776269213788; Wed, 15 Apr 2026\n 09:06:53 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>","In-Reply-To":"<73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>","From":"Gyorgy Tamasi ","Date":"Wed, 15 Apr 2026 18:06:44 +0200","X-Gm-Features":"AQROBzAXUvQXaXM95MnsuzJyD8OMlm3a5I916ysVQyUqacc68mgE0zjXrDjJk6k","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"gaosong ","Cc":"Huacai Chen ,\n Pierrick Bouvier ,\n laurent@vivier.eu, qemu-devel@nongnu.org,\n Peter Maydell ,\n Richard Henderson ,\n bibo mao , xianglai li ,\n pierrick.bouvier@posteo.net","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=2a00:1450:4864:20::132;\n envelope-from=gyorgy.tamasi@gmail.com; helo=mail-lf1-x132.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3678020,"web_url":"http://patchwork.ozlabs.org/comment/3678020/","msgid":"","list_archive_url":null,"date":"2026-04-16T08:53:27","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":5111,"url":"http://patchwork.ozlabs.org/api/people/5111/","name":"Peter Maydell","email":"peter.maydell@linaro.org"},"content":"On Mon, 13 Apr 2026 at 04:04, gaosong wrote:\n> I confirm that the same issue exists in the 9.2-tcg-old branch,\n> and you have clearly identified the root cause of the problem.\n> There is no doubt that the patch itself is fine, but what confuses\n> me is that you attempted to run (ABI 1.0.0) using QEMU (ABI 2.0),\n> which led to the misconception that QEMU (2.0) is compatible with\n> 1.0, when in fact QEMU has never been compatible with 1.0.\n> As far as I understand, the differences between the ABI 2.0 and\n> ABI 1.0 environments should be quite significant.\n>\n> Therefore, I am unsure whether we should accept this patch.\n\nFor upstream QEMU, we (as a policy choice) aren't supporting the\nold ABI. So we care only about the new ABI. Below I'm going to talk\nonly about the new ABI and what we do upstream; decisions about the\nold-ABI fork are for whoever maintains that.\n\nDefining the target_stat64 struct and TARGET_HAS_STRUCT_STAT64\naffects these syscalls:\n TARGET_NR_stat64\n TARGET_NR_lstat64\n TARGET_NR_fstat64\n TARGET_NR_fstatat64\n TARGET_NR_newfstatat\n\n(these are the only ones which call host_to_target_stat64().)\n\nOf these, loongarch64-linux-user defines only TARGET_NR_newfstatat.\n(You can check this by looking at the generated\nlibqemu-loongarch64-linux-user.a.p/syscall_nr.h in the build tree.\nExactly what gets defined here is controlled by the TARGET_SYSTBL_ABI\nsetting in configs/targets/loongarch64-linux-user.mak plus the\nlinux-user/loongarch64/syscall.tbl table.)\n\nThe kernel defines 'struct stat64' only if\n__BITS_PER_LONG != 64 || defined(__ARCH_WANT_STAT64).\nloongarch64 doesn't set __ARCH_WANT_STAT64, and it isn't 32-bit,\nso it won't get this struct.\n\nThe kernel also only provides the newfstatat syscall if\nthe architecture sets __ARCH_WANT_STAT64 or __ARCH_WANT_SYS_NEWFSTATAT.\nloongarch64 doesn't set either.\n\nSo:\n\n(1) We are providing newfstatat on this architecture when we\nshould not; that's a separate bug we should fix.\n\n(2) we don't want to define the stat64 struct in QEMU,\nbut it has gone unnoticed that we got this wrong because\nthe struct isn't actually used by any syscalls for this\narchitecture.\n\nThe code change in this patch is correct, and I think we should\ntake it, but it would be helpful to adjust the commit message\nto make it clear that for ABI-2.0 this doesn't actually\nhave any guest-code visible effects.\n\nthanks\n-- PMM","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=HHflbZR1;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxBdv2hGDz1yG9\n\tfor ; Thu, 16 Apr 2026 18:54:25 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wDITq-0005OS-Ci; Thu, 16 Apr 2026 04:53:48 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wDITm-0005Ny-HD\n for qemu-devel@nongnu.org; Thu, 16 Apr 2026 04:53:43 -0400","from mail-yx1-xb12a.google.com ([2607:f8b0:4864:20::b12a])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wDITk-0008F0-Q4\n for qemu-devel@nongnu.org; Thu, 16 Apr 2026 04:53:42 -0400","by mail-yx1-xb12a.google.com with SMTP id\n 956f58d0204a3-651c5d525f6so4492088d50.3\n for ; Thu, 16 Apr 2026 01:53:39 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776329618; cv=none;\n d=google.com; s=arc-20240605;\n b=OqiXrVL2rooa2pM7ImWHsyuWTP8twUTPe5qP0SBBfgqfyWUeXBtkV4CiuO0bIp7VHW\n PnN7KUKyKokDiRzQupuIMtqRsrmntqL+LskgSyk/PdUqVq5DuL7O11tL3cJ3wc8yg/jo\n n0z9OpX/UTQQ9YF1naPFOop8K/HzP1mkDwnBwJgGX7QU2Aed52rgTbkAGgrl8IRnGz2/\n BDuIrIwvZWO2UHdNWuqkByMh/xpder4NKRVLPzPPRI7szztEAAR62o5ir5WSxnaCEoF+\n GHUCIoFGZ4JMpVgiW/Yb53aYVWJ3SPW4+cqkmQZJFhsCX3KgWAyE0+ASTKeHNvWgtySY\n vQXw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=x5BDxbEeXuc3Pvvy5dNgf2LyYZeCp/NMK+KYefCTdyY=;\n fh=9DRnXINmPzvpmyEzFbwKbIaANfyGNvJUJ/hQx57tZow=;\n b=lYipgvaiikclEvDKoCia1ncR155bAb4Nn446KzCnO7KLmwIUYU1dSuUV8g6WcHdU/a\n u5eJE/7c9Q8IyVxIYn+LpPnPIiopdHJww19yjpC/BAoz3wXQPuDSvnD5FYUj57u2yfcg\n rOYtxRiFaWs4BwMNJ56GtilOpJ04vgjeEvDLMNINt1GR4l/mZFqNBbfdNbnFVCLxB8mB\n X1Xk1th8xiJ4JGYzy8lV/Tazz/OOSneFFUPWseGiQJ4+OeTQSzr/eAGWrJ1SwnINgGmL\n /ZsVMUHkcx7VqufdffP24OtAPXC2A39Eo3FGa3J35k+RUB+v86eP6NHaSS2N+YPNCBcQ\n AWBw==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776329618; x=1776934418; darn=nongnu.org;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=x5BDxbEeXuc3Pvvy5dNgf2LyYZeCp/NMK+KYefCTdyY=;\n b=HHflbZR16AtrZ0fuz5CIE5lGFMzNcqHOZ67BvChI057K78qpfQOq0N1AP1RWqT4/7W\n IWzSqQOxjCltF5ExJUp6PP7YbFYJ3A2EWhrtXePxPRvLhYMCx1zfz5uIaepaCfSTDxix\n +ANIz8VktEwbu8tHHsCBrABPhILyo+bug8OijL1dV3TNBr4LPGlqBoUuLjcV3qvupV3B\n ekC6EOR2DRtbTBsYom/my8VFK3LYV5yVEeB7scpKMLSddl13FKPnYYsWLnP7xjtDMdh6\n Y/5N3QRvB8yScc7Qk7lJqYh4cW7Zd3Z//iRF2HNMCYrcbPBT/5vVcPzYgXetaaq3lJCE\n 1Gtg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776329618; x=1776934418;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=x5BDxbEeXuc3Pvvy5dNgf2LyYZeCp/NMK+KYefCTdyY=;\n b=oKD5+G8+xmM9JIGP1EL3/zlGEZZfwI034rb2F7CEZ3s/O/wPA6xSUKwSZdbnskVME1\n 5kHLvRKFbUqWlBYvnRiercFnp8NEkmBFiYkfKqA4o0La6ggzHC/T36Q+3Z/HZz/TEY3H\n ei2VAZgLzCHi1PiFmvtMWuWuzIepfFxsUFw1B2aK6SJbKU/5+Us+BzwPJ1Jr+OkD4neU\n jfX6TwW2qC2X/D2+PT/m/Z4wv4H9MPyCFmmlPCtlvMtBVYaO5iLIa0gKTvgB18jJyP/V\n QqYz0a6YVHCxsVbSdd2m6q7gebZzTFVkXAeuZpKqP98ymQjRgufV48jDHZGh167o9P9Z\n GIvw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9fnFULJhUeuoaprzLoJdNDvt7swvXVRRMri4KjaxBn1vE551Iz4NpbAnpT1f1woBkis8asHgGfH1Qs@nongnu.org","X-Gm-Message-State":"AOJu0YzwS37ztkump5WFzSebcBLPOPRIYs2QZIQSAguS6baRZotOfPNB\n o8K6Wr2OVM0J6bo/3ySu/dqv1ZrBYv06JRQpr4WcxoyfM/OltGYVOngx7D3X8ZfWTSYp7gj5tam\n MGzMTxepp0PgbIQfad3LM+qwZ1VSrmIB4sgVUeBEeyA==","X-Gm-Gg":"AeBDiev1nVs889YDVYcbSPGI4AF2fU3x+FEx17MoiYAoElGOsWxFSG1ZWVw1h+IwSi/\n d2OLc7I9gK/FyZhc5dYDtT2k3FV8JM7b4wy+0AmrWo6G/kwvrHPjIheFqjUS6OfWIt39fo0skr9\n ozYN8x0di4PALltlfoeFqacT3j2P04hx7qoeFIpQ9dwjpv1kdqfkWgeOr+zQqns62XWV5+Jfqf6\n HPkzI+5H5/jG5CazNgKjZ+gwc2HVkyV/qEPb15ozzotHavvT3knRBF96m1vrf4IYJz93efINLXH\n KlaJQWrIaa44H8ajDh/PEre5EtnvaGPEEPbXC/97ujQQwtl0luo5A49K0bI89S7zDkWIDiJSnFa\n Xzg==","X-Received":"by 2002:a05:690e:d45:b0:651:bed1:19f8 with SMTP id\n 956f58d0204a3-651bed12ac2mr15152924d50.26.1776329618558; Thu, 16 Apr 2026\n 01:53:38 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>","In-Reply-To":"<73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>","From":"Peter Maydell ","Date":"Thu, 16 Apr 2026 09:53:27 +0100","X-Gm-Features":"AQROBzCmoW9pMp_7ZZGodcYA9Zhgf1Ez-WADljCTqBgkrSwEJA6BBopE1Z3_lug","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"gaosong ","Cc":"Gyorgy Tamasi ,\n Huacai Chen ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Richard Henderson ,\n bibo mao , xianglai li ","Content-Type":"text/plain; charset=\"UTF-8\"","Received-SPF":"pass client-ip=2607:f8b0:4864:20::b12a;\n envelope-from=peter.maydell@linaro.org; helo=mail-yx1-xb12a.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3678134,"web_url":"http://patchwork.ozlabs.org/comment/3678134/","msgid":"","list_archive_url":null,"date":"2026-04-16T12:29:30","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":82024,"url":"http://patchwork.ozlabs.org/api/people/82024/","name":"Song Gao","email":"gaosong@loongson.cn"},"content":"在 2026/4/16 上午12:06, Gyorgy Tamasi 写道:\n> Hi,\n>\n> This is a very simple change within a broader and more complex logical\n> context. It has an important property: it targets a single specific\n> QEMU configuration (LOONGARCH64) and has no possible side effects for\n> other configurations. Additionally, it can only have a positive effect\n> in any context (in any QEMU fork) when the modified code is\n> executed—even in non-standard or unexpected scenarios, such as\n> attempting to run an ABI 1.0 binary using a qemu-user-loongarch64\n> build intended for ABI 2.0. In such cases, if the limited (non-ABI\n> 2.0–specific) feature set of the ABI 1.0 application happens to allow\n> execution, this change still behaves safely. In this sense, it follows\n> a fundamental principle of software bug fixing (and medicine): primum\n> non nocere (“first, do no harm”). 🙂\n>\n> I understand that we are currently in the middle of an important\n> transition period, during which even traditionally “Old World” (ABI\n> 1.0–dependent) LoongArch64 Linux distributions are releasing their\n> “New World” (ABI 2.0–specific) versions.\n>\n> I do not feel qualified to estimate the duration of the next phase of\n> this transition, namely the replacement of ABI 1.0 OS installations\n> with ABI 2.0 versions in the end-user base. If a company plans to\n> release something for LoongArch64 now, and its goal is to make it\n> available to as many users as possible, building for ABI 2.0—and\n> optionally also for ABI 1.0—may still be a reasonable choice (provided\n> a sufficiently large number of users are still on ABI 1.0 systems\n> before they upgrade).\n>\n> My (admittedly very specific) personal perspective: I do not yet have\n> access to real LoongArch64 hardware, so I have been testing both ABI\n> 2.0 and ABI 1.0 LA64 binaries using different qemu-user versions (even\n> if this is not a typical use case). Since I have already applied this\n> modification in my own qemu-user builds, the issue no longer affects\n> me. Therefore, I can accept that this fix may not be integrated into\n> the official QEMU branches (given that it concerns the now phasing-out\n> ABI 1.0). The decision is beyond my scope.\nHi,\n\nThank you for your explanation. QEMU 11.0 is currently in the RC4 stage,\nso I believe we can merge this patch in the next cycle.\nThank you again for your contribution to QEMU.\n\n\nThanks.\nSong Gao\n> Best regards,\n> -tgy\n>\n>\n> On Mon, Apr 13, 2026 at 5:04 AM gaosong wrote:\n>> 在 2026/4/11 下午6:39, Gyorgy Tamasi 写道:\n>>>>> This changeset was the last mod of syscall_defs.h - but it still\n>>>>> incorrectly modifies the condition of struct target_stat64 usage:\n>>>>> (~ \"Add Loongarch64 old ABI support\")\n>>>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n>>>>> (line 2006)\n>>>>> -----\n>>>>> -#if !defined(TARGET_RISCV64)\n>>>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n>>>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n>>>> Huacai\n>>> But here the added \"|| defined(TARGET_LOONGARCH64)\" part doesn't fix\n>>> that affected bug similar to RISCV[32] vs. RISCV64...you need \"&&\n>>> !defined(TARGET_LOONGARCH64)\" here to create an effect for\n>>> TARGET_LOONGARCH64 similar to the proper solution for TARGET_RISCV64\n>>> (~ disable the use of this struct target_stat64 with 32bit sec/nsec\n>>> fields for a glibc environment where 64bit sec/nsecs are used - the\n>>> default struct target_stat is perfect for these 64bit envs, do not let\n>>> TARGET_HAS_STRUCT_STAT64 to be defined). [This 2nd embedded \"||\n>>> defined(TARGET_LOONGARCH64)\" within an other encapsulating \"||\n>>> defined(TARGET_LOONGARCH64)\" #elif-section is effectively a no-op here\n>>> (the 2nd is always true, if the encapsulating 1st was true)...it does\n>>> not effectively change the behaviour of its conditional\n>>> code-fragment-body in the actual context...comparing to the original\n>>> \"#if !defined(TARGET_RISCV64)\" full-line.]\n>>>\n>>> How the contexts of LoongArch64 ABI1.0 vs. ABI2.0 are linked to this\n>>> issue (related to an optional code-path in qemu/linux-user/syscall.c)?\n>>> The answer:\n>>> The existence of this bug does not directly depend on or linked to any\n>>> difference of core features of LA64's ABI1.0 vs. ABI2.0.\n>>> The difference in behaviour of ABI1.0 and ABI2.0 environments related\n>>> to this qemu-code-part here strictly depends on the behaviour of\n>>> specific glibc versions used by those LA64 ABI1.0 and ABI2.0\n>>> environments.\n>>>\n>>> In the ABI1.0 env of glibc-2.28-7cdc44d5a1 used by Loongson's gcc 8.3\n>>> rc1.6 a stat-like call (filling up a struct stat instance) IS NOT\n>>> always routed via the statx syscall, newfstatat can be used\n>>> instead!...and the processing of this newfstatat triggers the usage of\n>>> the problematic code-path in qemu/linux-user/syscall.c having this\n>>> bug, related to the host_to_target_stat64() function, where this code\n>>> fragment prefers to use struct target_stat64 (instead of struct\n>>> target_stat), if its use is enabled by\n>>> defined(TARGET_HAS_STRUCT_STAT64):\n>>> (~ around line 7975 in the 10.2.2 source)\n>>> #if defined(TARGET_HAS_STRUCT_STAT64)\n>>> struct target_stat64 *target_st;\n>>> #else\n>>> struct target_stat *target_st;\n>>> #endif\n>>>\n>>> While in the ABI2.0 env of glibc of this gcc\n>>> https://github.com/loongson/build-tools/releases/download/2025.08.08/x86_64-cross-tools-loongarch64-binutils_2.45-gcc_15.1.0-glibc_2.42.tar.xz\n>>> from https://github.com/loongson/build-tools (glibc:\n>>> https://ftp.gnu.org/gnu/glibc/glibc-2.42.tar.xz) ALL stat-like calls\n>>> ARE ROUTED via the statx syscall, so the problematic code path of\n>>> host_to_target_stat64() IS NOT used/triggered at all (and processing\n>>> path of the statx syscall in linux-user/syscall.c is correct). This\n>>> behaviour of glibc-2.42 can be determined by these definitions in\n>>> glibc-2.42/sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h:\n>>> -----\n>>> /* To avoid the messy usage of the fstat, newfstatat, and statx system calls, we\n>>> only use statx. */\n>>> #undef __NR_fstat\n>>> #undef __NR_newfstatat\n>>> -----\n>>>\n>>> -tgy\n>> Hi,\n>>\n>> Thank you for your explanation.\n>>\n>> I confirm that the same issue exists in the 9.2-tcg-old branch, and you have clearly identified the root cause of the problem.\n>> There is no doubt that the patch itself is fine, but what confuses me is that you attempted to run (ABI 1.0.0) using QEMU (ABI 2.0),\n>> which led to the misconception that QEMU (2.0) is compatible with 1.0, when in fact QEMU has never been compatible with 1.0.\n>> As far as I understand, the differences between the ABI 2.0 and ABI 1.0 environments should be quite significant.\n>>\n>> Therefore, I am unsure whether we should accept this patch.\n>> Should we submit this patch to the 9.2-tcg-0ld branch?\n>> Or should you consider discontinuing support for ABI 1.0? To my knowledge, ABI 2.0 has now become the mainstream standard.\n>>\n>> Thanks.\n>> Song Gao\n>>\n>>> On Sat, Apr 11, 2026 at 10:24 AM Huacai Chen wrote:\n>>>> On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi wrote:\n>>>>> Hi,\n>>>>>\n>>>>> Thanks for the link of this separate Loongson-maintained 9.2-tcg-old\n>>>>> branch - intended for use specifically with ABI 1.0 code.\n>>>>>\n>>>>> This separate branch still contains the same bug (in the context of\n>>>>> the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\n>>>>> fstatat syscall can be used by glibc, and it can trigger the usage of\n>>>>> the related erroneous data-conversion workflow based on struct\n>>>>> target_stat64 with 4byte sec/nsec fields):\n>>>>>\n>>>>> This changeset was the last mod of syscall_defs.h - but it still\n>>>>> incorrectly modifies the condition of struct target_stat64 usage:\n>>>>> (~ \"Add Loongarch64 old ABI support\")\n>>>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n>>>>> (line 2006)\n>>>>> -----\n>>>>> -#if !defined(TARGET_RISCV64)\n>>>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n>>>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n>>>>\n>>>> Huacai\n>>>>\n>>>>> -----\n>>>>>\n>>>>> This is the broader context in this 9.2-tcg-old original version:\n>>>>> Here the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\n>>>>> no-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\n>>>>> is true/false.\n>>>>> -----\n>>>>> #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n>>>>> || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n>>>>> defined(TARGET_LOONGARCH64)\n>>>>> /* These are the asm-generic versions of the stat and stat64 structures */\n>>>>>\n>>>>> #define TARGET_STAT_HAVE_NSEC\n>>>>> struct target_stat {\n>>>>> ...\n>>>>> };\n>>>>>\n>>>>> #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>>> #define TARGET_HAS_STRUCT_STAT64\n>>>>> struct target_stat64 {\n>>>>> ...\n>>>>> };\n>>>>> #endif\n>>>>>\n>>>>> #elif defined(TARGET_HPPA)\n>>>>> -----\n>>>>>\n>>>>> The correct fix is the same here (~ disable the use of this struct\n>>>>> target_stat64 - instead of explicitly enabling it for\n>>>>> TARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n>>>>> -----\n>>>>> ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n>>>>> --- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n>>>>> +++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n>>>>> @@ -2003,7 +2003,7 @@\n>>>>> abi_uint __unused5;\n>>>>> };\n>>>>>\n>>>>> -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>>> +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n>>>>> #define TARGET_HAS_STRUCT_STAT64\n>>>>> struct target_stat64 {\n>>>>> abi_ullong st_dev;\n>>>>> -----\n>>>>>\n>>>>> The same test-scenario of\n>>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n>>>>> [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\n>>>>> toolset] to show exactly the same bad & good test results - without &\n>>>>> with this mod.\n>>>>>\n>>>>> Just a personal experience based side-note on ABI1.0 compatibility\n>>>>> with mainline qemu (~10.2.2):\n>>>>> I'm working on porting a quite large code-base (a commercial OCR &\n>>>>> document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\n>>>>> I'm trying to check correctness of my actual builds using the\n>>>>> regression-test package of this codebase. It runs quite complex\n>>>>> workflows of general CLI code. I accept that this is not a\n>>>>> comprehensive test with all of the edge cases or touching every\n>>>>> special areas (like signal handling) of compatibility of ABI1.0 and\n>>>>> mainline qemu, but...the ABI1.0 version of this test-code seems to be\n>>>>> able to run with mainline qemu-user 10.2.2.\n>>>>>\n>>>>> Best regards,\n>>>>> -tgy\n>>>>>\n>>>>> On Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n>>>>>> 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n>>>>>>> Tested-by: Gyorgy Tamasi \n>>>>>>>\n>>>>>>> Additional independent testing (bug + fix cases) is documented here -\n>>>>>>> see comments by sourav/@kishu279:\n>>>>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>>>>>> Hi.\n>>>>>> Please note that QEMU is not compatible with ABI 1.0.\n>>>>>>\n>>>>>> If you absolutely must use ABI 1.0, the branch below is the version we use.\n>>>>>> https://github.com/loongson/qemu/commits/9.2-tcg-old/\n>>>>>>\n>>>>>> However, this branch is quite far from the mainline.\n>>>>>> The QEMU mainline follows the kernel mainline, and\n>>>>>> I believe this is the case for other architectures as well.\n>>>>>>\n>>>>>> Thanks.\n>>>>>> Song Gao\n>>>>>>> On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n>>>>>>> wrote:\n>>>>>>>> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n>>>>>>>>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n>>>>>>>>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n>>>>>>>>> target_stat64 for data-transfer, since this struct target_stat64 is\n>>>>>>>>> defined for 32bit environments with its int-sized (4byte) st_*time\n>>>>>>>>> sec/nsec components.\n>>>>>>>>> The user side compiler headers of the LoongArch64 env uses long-sized\n>>>>>>>>> (8byte) st_*time sec/nsec components.\n>>>>>>>>>\n>>>>>>>>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n>>>>>>>>> code does not use struct target_stat64 in 64bit RISCV env, when both\n>>>>>>>>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n>>>>>>>>>\n>>>>>>>>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n>>>>>>>>> fstatat syscall with this struct target_stat64, if its usage is\n>>>>>>>>> enabled.\n>>>>>>>>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n>>>>>>>>> problematic struct target_stat64 is not used, struct statx is correct\n>>>>>>>>> in the LoongArch64 env.)\n>>>>>>>>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>>>>>>>>>\n>>>>>>>>> Signed-off-by: Gyorgy Tamasi \n>>>>>>>>> ---\n>>>>>>>>> linux-user/syscall_defs.h | 2 +-\n>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>>>>>>>>\n>>>>>>>> Reviewed-by: Pierrick Bouvier ","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxHPv3wNsz1yG9\n\tfor ; Thu, 16 Apr 2026 22:29:22 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wDLpv-00017e-B0; Thu, 16 Apr 2026 08:28:47 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wDLpm-00017N-5O\n for qemu-devel@nongnu.org; Thu, 16 Apr 2026 08:28:38 -0400","from mail.loongson.cn ([114.242.206.163])\n by eggs.gnu.org with esmtp (Exim 4.90_1)\n (envelope-from ) id 1wDLph-00081j-JN\n for qemu-devel@nongnu.org; Thu, 16 Apr 2026 08:28:37 -0400","from loongson.cn (unknown [10.20.42.239])\n by gateway (Coremail) with SMTP id _____8AxI_Dn1eBpsCMBAA--.4937S3;\n Thu, 16 Apr 2026 20:28:23 +0800 (CST)","from [10.20.42.239] (unknown [10.20.42.239])\n by front1 (Coremail) with SMTP id qMiowJDx6+Db1eBpwX1uAA--.14624S3;\n Thu, 16 Apr 2026 20:28:19 +0800 (CST)"],"Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Gyorgy Tamasi ","Cc":"Huacai Chen ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Peter Maydell ,\n Richard Henderson ,\n bibo mao , xianglai li ,\n pierrick.bouvier@posteo.net","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>\n ","From":"gaosong ","Message-ID":"","Date":"Thu, 16 Apr 2026 20:29:30 +0800","User-Agent":"Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101\n Thunderbird/68.7.0","MIME-Version":"1.0","In-Reply-To":"\n ","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","X-CM-TRANSID":"qMiowJDx6+Db1eBpwX1uAA--.14624S3","X-CM-SenderInfo":"5jdr20tqj6z05rqj20fqof0/","X-Coremail-Antispam":"1Uk129KBj9fXoW3KryrZw1UCF47CFWDtFWrWFX_yoW8GrWfZo\n W3Jr4xJw4xJr1rZF4qk39rJFy7Ww1UCr15JrW7X348GFnIqw1UGw1xJ3yrXFWayF95Ka98\n Ja45Jan8ZFWxJF93l-sFpf9Il3svdjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8wcxFpf\n 9Il3svdxBIdaVrn0xqx4xG64xvF2IEw4CE5I8CrVC2j2Jv73VFW2AGmfu7bjvjm3AaLaJ3\n UjIYCTnIWjp_UUUYx7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI\n 8IcIk0rVWrJVCq3wAFIxvE14AKwVWUXVWUAwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xG\n Y2AK021l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14\n v26r1j6r4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAF\n wI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI\n 0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280\n aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2\n xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAq\n x4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r\n 43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF\n 7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxV\n WUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jU\n sqXUUUUU=","Received-SPF":"pass client-ip=114.242.206.163;\n envelope-from=gaosong@loongson.cn;\n helo=mail.loongson.cn","X-Spam_score_int":"-49","X-Spam_score":"-5.0","X-Spam_bar":"-----","X-Spam_report":"(-5.0 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-3.135,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3678327,"web_url":"http://patchwork.ozlabs.org/comment/3678327/","msgid":"","list_archive_url":null,"date":"2026-04-16T19:14:48","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":93091,"url":"http://patchwork.ozlabs.org/api/people/93091/","name":"Gyorgy Tamasi","email":"gyorgy.tamasi@gmail.com"},"content":"Hi Peter,\n\nYour analysis cleared some things related to this older changeset:\nhttps://github.com/qemu/qemu/commit/c52e405968341b1d10c618f23bdbb841e39f9255\n\nBefore this syscall-NR 79 & 80 (newfstatat & fstat) was not enumerated\nin the old/deleted (non-generated)\nlinux-user/loongarch64/syscall_nr.h‎...but these appeared again in the\nnewly created linux-user/loongarch64/syscall.tbl‎.\n\nI can recall that I was getting \"Unknown syscall\" messages for 79 &\n80, when I tried to run qemu-user 8.x.x even with the simplest ABI 1.0\nexecutable, because even the shared-lib loading phase failed on these\nmissing syscalls 79 & 80 (used by the old glibc env of that ABI 1.0\nexe). So in the case of that older qemu-user 8.x.x it was obvious that\nit is not compatible with ABI 1.0.\n\nThanks,\n-tgy\n\nOn Thu, Apr 16, 2026 at 2:28 PM gaosong wrote:\n>\n> 在 2026/4/16 上午12:06, Gyorgy Tamasi 写道:\n> > Hi,\n> >\n> > This is a very simple change within a broader and more complex logical\n> > context. It has an important property: it targets a single specific\n> > QEMU configuration (LOONGARCH64) and has no possible side effects for\n> > other configurations. Additionally, it can only have a positive effect\n> > in any context (in any QEMU fork) when the modified code is\n> > executed—even in non-standard or unexpected scenarios, such as\n> > attempting to run an ABI 1.0 binary using a qemu-user-loongarch64\n> > build intended for ABI 2.0. In such cases, if the limited (non-ABI\n> > 2.0–specific) feature set of the ABI 1.0 application happens to allow\n> > execution, this change still behaves safely. In this sense, it follows\n> > a fundamental principle of software bug fixing (and medicine): primum\n> > non nocere (“first, do no harm”). 🙂\n> >\n> > I understand that we are currently in the middle of an important\n> > transition period, during which even traditionally “Old World” (ABI\n> > 1.0–dependent) LoongArch64 Linux distributions are releasing their\n> > “New World” (ABI 2.0–specific) versions.\n> >\n> > I do not feel qualified to estimate the duration of the next phase of\n> > this transition, namely the replacement of ABI 1.0 OS installations\n> > with ABI 2.0 versions in the end-user base. If a company plans to\n> > release something for LoongArch64 now, and its goal is to make it\n> > available to as many users as possible, building for ABI 2.0—and\n> > optionally also for ABI 1.0—may still be a reasonable choice (provided\n> > a sufficiently large number of users are still on ABI 1.0 systems\n> > before they upgrade).\n> >\n> > My (admittedly very specific) personal perspective: I do not yet have\n> > access to real LoongArch64 hardware, so I have been testing both ABI\n> > 2.0 and ABI 1.0 LA64 binaries using different qemu-user versions (even\n> > if this is not a typical use case). Since I have already applied this\n> > modification in my own qemu-user builds, the issue no longer affects\n> > me. Therefore, I can accept that this fix may not be integrated into\n> > the official QEMU branches (given that it concerns the now phasing-out\n> > ABI 1.0). The decision is beyond my scope.\n> Hi,\n>\n> Thank you for your explanation. QEMU 11.0 is currently in the RC4 stage,\n> so I believe we can merge this patch in the next cycle.\n> Thank you again for your contribution to QEMU.\n>\n>\n> Thanks.\n> Song Gao\n> > Best regards,\n> > -tgy\n> >\n> >\n> > On Mon, Apr 13, 2026 at 5:04 AM gaosong wrote:\n> >> 在 2026/4/11 下午6:39, Gyorgy Tamasi 写道:\n> >>>>> This changeset was the last mod of syscall_defs.h - but it still\n> >>>>> incorrectly modifies the condition of struct target_stat64 usage:\n> >>>>> (~ \"Add Loongarch64 old ABI support\")\n> >>>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n> >>>>> (line 2006)\n> >>>>> -----\n> >>>>> -#if !defined(TARGET_RISCV64)\n> >>>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >>>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n> >>>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n> >>>> Huacai\n> >>> But here the added \"|| defined(TARGET_LOONGARCH64)\" part doesn't fix\n> >>> that affected bug similar to RISCV[32] vs. RISCV64...you need \"&&\n> >>> !defined(TARGET_LOONGARCH64)\" here to create an effect for\n> >>> TARGET_LOONGARCH64 similar to the proper solution for TARGET_RISCV64\n> >>> (~ disable the use of this struct target_stat64 with 32bit sec/nsec\n> >>> fields for a glibc environment where 64bit sec/nsecs are used - the\n> >>> default struct target_stat is perfect for these 64bit envs, do not let\n> >>> TARGET_HAS_STRUCT_STAT64 to be defined). [This 2nd embedded \"||\n> >>> defined(TARGET_LOONGARCH64)\" within an other encapsulating \"||\n> >>> defined(TARGET_LOONGARCH64)\" #elif-section is effectively a no-op here\n> >>> (the 2nd is always true, if the encapsulating 1st was true)...it does\n> >>> not effectively change the behaviour of its conditional\n> >>> code-fragment-body in the actual context...comparing to the original\n> >>> \"#if !defined(TARGET_RISCV64)\" full-line.]\n> >>>\n> >>> How the contexts of LoongArch64 ABI1.0 vs. ABI2.0 are linked to this\n> >>> issue (related to an optional code-path in qemu/linux-user/syscall.c)?\n> >>> The answer:\n> >>> The existence of this bug does not directly depend on or linked to any\n> >>> difference of core features of LA64's ABI1.0 vs. ABI2.0.\n> >>> The difference in behaviour of ABI1.0 and ABI2.0 environments related\n> >>> to this qemu-code-part here strictly depends on the behaviour of\n> >>> specific glibc versions used by those LA64 ABI1.0 and ABI2.0\n> >>> environments.\n> >>>\n> >>> In the ABI1.0 env of glibc-2.28-7cdc44d5a1 used by Loongson's gcc 8.3\n> >>> rc1.6 a stat-like call (filling up a struct stat instance) IS NOT\n> >>> always routed via the statx syscall, newfstatat can be used\n> >>> instead!...and the processing of this newfstatat triggers the usage of\n> >>> the problematic code-path in qemu/linux-user/syscall.c having this\n> >>> bug, related to the host_to_target_stat64() function, where this code\n> >>> fragment prefers to use struct target_stat64 (instead of struct\n> >>> target_stat), if its use is enabled by\n> >>> defined(TARGET_HAS_STRUCT_STAT64):\n> >>> (~ around line 7975 in the 10.2.2 source)\n> >>> #if defined(TARGET_HAS_STRUCT_STAT64)\n> >>> struct target_stat64 *target_st;\n> >>> #else\n> >>> struct target_stat *target_st;\n> >>> #endif\n> >>>\n> >>> While in the ABI2.0 env of glibc of this gcc\n> >>> https://github.com/loongson/build-tools/releases/download/2025.08.08/x86_64-cross-tools-loongarch64-binutils_2.45-gcc_15.1.0-glibc_2.42.tar.xz\n> >>> from https://github.com/loongson/build-tools (glibc:\n> >>> https://ftp.gnu.org/gnu/glibc/glibc-2.42.tar.xz) ALL stat-like calls\n> >>> ARE ROUTED via the statx syscall, so the problematic code path of\n> >>> host_to_target_stat64() IS NOT used/triggered at all (and processing\n> >>> path of the statx syscall in linux-user/syscall.c is correct). This\n> >>> behaviour of glibc-2.42 can be determined by these definitions in\n> >>> glibc-2.42/sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h:\n> >>> -----\n> >>> /* To avoid the messy usage of the fstat, newfstatat, and statx system calls, we\n> >>> only use statx. */\n> >>> #undef __NR_fstat\n> >>> #undef __NR_newfstatat\n> >>> -----\n> >>>\n> >>> -tgy\n> >> Hi,\n> >>\n> >> Thank you for your explanation.\n> >>\n> >> I confirm that the same issue exists in the 9.2-tcg-old branch, and you have clearly identified the root cause of the problem.\n> >> There is no doubt that the patch itself is fine, but what confuses me is that you attempted to run (ABI 1.0.0) using QEMU (ABI 2.0),\n> >> which led to the misconception that QEMU (2.0) is compatible with 1.0, when in fact QEMU has never been compatible with 1.0.\n> >> As far as I understand, the differences between the ABI 2.0 and ABI 1.0 environments should be quite significant.\n> >>\n> >> Therefore, I am unsure whether we should accept this patch.\n> >> Should we submit this patch to the 9.2-tcg-0ld branch?\n> >> Or should you consider discontinuing support for ABI 1.0? To my knowledge, ABI 2.0 has now become the mainstream standard.\n> >>\n> >> Thanks.\n> >> Song Gao\n> >>\n> >>> On Sat, Apr 11, 2026 at 10:24 AM Huacai Chen wrote:\n> >>>> On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi wrote:\n> >>>>> Hi,\n> >>>>>\n> >>>>> Thanks for the link of this separate Loongson-maintained 9.2-tcg-old\n> >>>>> branch - intended for use specifically with ABI 1.0 code.\n> >>>>>\n> >>>>> This separate branch still contains the same bug (in the context of\n> >>>>> the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\n> >>>>> fstatat syscall can be used by glibc, and it can trigger the usage of\n> >>>>> the related erroneous data-conversion workflow based on struct\n> >>>>> target_stat64 with 4byte sec/nsec fields):\n> >>>>>\n> >>>>> This changeset was the last mod of syscall_defs.h - but it still\n> >>>>> incorrectly modifies the condition of struct target_stat64 usage:\n> >>>>> (~ \"Add Loongarch64 old ABI support\")\n> >>>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n> >>>>> (line 2006)\n> >>>>> -----\n> >>>>> -#if !defined(TARGET_RISCV64)\n> >>>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >>>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n> >>>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n> >>>>\n> >>>> Huacai\n> >>>>\n> >>>>> -----\n> >>>>>\n> >>>>> This is the broader context in this 9.2-tcg-old original version:\n> >>>>> Here the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\n> >>>>> no-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\n> >>>>> is true/false.\n> >>>>> -----\n> >>>>> #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n> >>>>> || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n> >>>>> defined(TARGET_LOONGARCH64)\n> >>>>> /* These are the asm-generic versions of the stat and stat64 structures */\n> >>>>>\n> >>>>> #define TARGET_STAT_HAVE_NSEC\n> >>>>> struct target_stat {\n> >>>>> ...\n> >>>>> };\n> >>>>>\n> >>>>> #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >>>>> #define TARGET_HAS_STRUCT_STAT64\n> >>>>> struct target_stat64 {\n> >>>>> ...\n> >>>>> };\n> >>>>> #endif\n> >>>>>\n> >>>>> #elif defined(TARGET_HPPA)\n> >>>>> -----\n> >>>>>\n> >>>>> The correct fix is the same here (~ disable the use of this struct\n> >>>>> target_stat64 - instead of explicitly enabling it for\n> >>>>> TARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n> >>>>> -----\n> >>>>> ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n> >>>>> --- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n> >>>>> +++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n> >>>>> @@ -2003,7 +2003,7 @@\n> >>>>> abi_uint __unused5;\n> >>>>> };\n> >>>>>\n> >>>>> -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n> >>>>> +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n> >>>>> #define TARGET_HAS_STRUCT_STAT64\n> >>>>> struct target_stat64 {\n> >>>>> abi_ullong st_dev;\n> >>>>> -----\n> >>>>>\n> >>>>> The same test-scenario of\n> >>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n> >>>>> [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\n> >>>>> toolset] to show exactly the same bad & good test results - without &\n> >>>>> with this mod.\n> >>>>>\n> >>>>> Just a personal experience based side-note on ABI1.0 compatibility\n> >>>>> with mainline qemu (~10.2.2):\n> >>>>> I'm working on porting a quite large code-base (a commercial OCR &\n> >>>>> document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\n> >>>>> I'm trying to check correctness of my actual builds using the\n> >>>>> regression-test package of this codebase. It runs quite complex\n> >>>>> workflows of general CLI code. I accept that this is not a\n> >>>>> comprehensive test with all of the edge cases or touching every\n> >>>>> special areas (like signal handling) of compatibility of ABI1.0 and\n> >>>>> mainline qemu, but...the ABI1.0 version of this test-code seems to be\n> >>>>> able to run with mainline qemu-user 10.2.2.\n> >>>>>\n> >>>>> Best regards,\n> >>>>> -tgy\n> >>>>>\n> >>>>> On Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n> >>>>>> 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n> >>>>>>> Tested-by: Gyorgy Tamasi \n> >>>>>>>\n> >>>>>>> Additional independent testing (bug + fix cases) is documented here -\n> >>>>>>> see comments by sourav/@kishu279:\n> >>>>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> >>>>>> Hi.\n> >>>>>> Please note that QEMU is not compatible with ABI 1.0.\n> >>>>>>\n> >>>>>> If you absolutely must use ABI 1.0, the branch below is the version we use.\n> >>>>>> https://github.com/loongson/qemu/commits/9.2-tcg-old/\n> >>>>>>\n> >>>>>> However, this branch is quite far from the mainline.\n> >>>>>> The QEMU mainline follows the kernel mainline, and\n> >>>>>> I believe this is the case for other architectures as well.\n> >>>>>>\n> >>>>>> Thanks.\n> >>>>>> Song Gao\n> >>>>>>> On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n> >>>>>>> wrote:\n> >>>>>>>> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n> >>>>>>>>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n> >>>>>>>>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n> >>>>>>>>> target_stat64 for data-transfer, since this struct target_stat64 is\n> >>>>>>>>> defined for 32bit environments with its int-sized (4byte) st_*time\n> >>>>>>>>> sec/nsec components.\n> >>>>>>>>> The user side compiler headers of the LoongArch64 env uses long-sized\n> >>>>>>>>> (8byte) st_*time sec/nsec components.\n> >>>>>>>>>\n> >>>>>>>>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n> >>>>>>>>> code does not use struct target_stat64 in 64bit RISCV env, when both\n> >>>>>>>>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n> >>>>>>>>>\n> >>>>>>>>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n> >>>>>>>>> fstatat syscall with this struct target_stat64, if its usage is\n> >>>>>>>>> enabled.\n> >>>>>>>>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n> >>>>>>>>> problematic struct target_stat64 is not used, struct statx is correct\n> >>>>>>>>> in the LoongArch64 env.)\n> >>>>>>>>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n> >>>>>>>>>\n> >>>>>>>>> Signed-off-by: Gyorgy Tamasi \n> >>>>>>>>> ---\n> >>>>>>>>> linux-user/syscall_defs.h | 2 +-\n> >>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n> >>>>>>>>>\n> >>>>>>>> Reviewed-by: Pierrick Bouvier \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=A5cLzXs3;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxSQk54Wkz1yD3\n\tfor ; Fri, 17 Apr 2026 05:15:41 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wDSBA-0001he-A0; Thu, 16 Apr 2026 15:15:08 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wDSB8-0001hS-OB\n for qemu-devel@nongnu.org; Thu, 16 Apr 2026 15:15:06 -0400","from mail-lf1-x132.google.com ([2a00:1450:4864:20::132])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wDSB5-0004rK-OI\n for qemu-devel@nongnu.org; Thu, 16 Apr 2026 15:15:06 -0400","by mail-lf1-x132.google.com with SMTP id\n 2adb3069b0e04-5a2b5ea59a1so9722336e87.1\n for ; Thu, 16 Apr 2026 12:15:02 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776366901; cv=none;\n d=google.com; s=arc-20240605;\n b=j36f8moSEhp9DBuQhkZTQp/c/eNftIAa/gJX8NiWLK0XoZQFUFT4KvSlEhf9+S7tWt\n +zaXHPycHq508UMnTrHQG/SX34/VkRymjtfU0Jw3zGMCnoA4qd/x/8KaX4dgLdpF7dI3\n JDTe49mnXRX4+6fd2D/L7YMVrFNs2tY2lyTB8ZbaANrYKA2WtLYSTb4+RSSHsyq1zYF9\n ZBBO/89vjxbqENbZFnGt+IS1gXDq+U9k6vRRoucJ8wCsgoPgAM+WbljQxbhlKEp8UMMk\n ajMOuVRvQ68/K4bItsxjH9KjtFawlFYwPTbiDm21+cysMIfH9zP0zVWJlgWnoxdbIfs1\n 0KPg==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=1KBiw9e54T85+xhxn3ZGWn3hcGocgNS1tcyqHWjq6AQ=;\n fh=QeTCJKyjuh9K9E+DzzfPPOR0IN9HPCIqyaTqoKCS9VQ=;\n b=al+LdDVxCtEiVcWwLX3LxXQTNxoNmaVya5pPrjTQhSDHxERAvU/Vf6X+y4d9puQ3WP\n Ok82Z4bP0XG7A3K/GTg421E75jtuS68O0wj7toj0JuhrGtmPJlY3wvWOOfCG7HXN3LKG\n mILzppPiOYJApwT9sYA0P3eN5cX9L8O4K5inOTrVTlkNgJktzCeFwcs9/YeLr5O5TbUt\n frfgZccByOKWSKx05bJ+BXB1YyYmeU1cl5SquzDI1QnJltafnKIFOeFrdmAROlg5WC1R\n zXrONf04TwZ3iTLdCpzX5eOis933bcV6UsCjfqNd8/fxULr7sxy55ecFXn1dVs4ski1B\n ic9g==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1776366901; x=1776971701; darn=nongnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=1KBiw9e54T85+xhxn3ZGWn3hcGocgNS1tcyqHWjq6AQ=;\n b=A5cLzXs3FljaA69/kgQsG1uIKiwUaheIbIr1wDBOGf122xDR6LwHzr7ghcKAYlro8Q\n OqUzaiVedZLBrXgXU+eM6FIkIzro1lkjznJacjkf8xJLwlVfhw/RL1FNuLj3zb49OnBJ\n bdnirqH70jVdNvsq/lw3SvSDS1ckLPLxIq4oS11MFOMqn/azDJehSNk5IC2aQZSOmPue\n Zfyk1DaZt9ZyhHK4aHhpyEW3GiyOErvfR5sfYyZBWK9xU56uAOYQKqX/dI6CgvKG7MFT\n +O/fQ0spEuxUklRS7lNyAAmK45S9AN+hkTocRxsX5hX+kAmUyG+DA1IZrLmBEhmg3+Sh\n YmmQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776366901; x=1776971701;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=1KBiw9e54T85+xhxn3ZGWn3hcGocgNS1tcyqHWjq6AQ=;\n b=jFHNI1HhiC5jA544ikf7Z6MsYlqabuEv0nuIsKpuYaRFM+W0p/PcDO8i388ob4+C4U\n K14tYgSslDyAd4cSwSkZWZjP3LWap7SQYZFXFvPqVBZfr3FplEEHB9qhsm+0u9acpMWu\n k7PY/TrHstp9PMuIS/kqwuKcY5AEsYorzHdr+c0ybneXnrjMEwCJ21QKVMVwRsCb96Oj\n dnsmFLqlluhSe2gzelTex//SDYsSr6Y08HbIUNVNGcZNhbSZJDDvuHElVpLvi6XAe54J\n lCHxPFKxXZWOeHEd5Su2HpawMBfy1rhL1qijT6aXqkAFuZdrbNRFFDkPlnwD4Lv+HefU\n 3thw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9gqXuMcVcnuYVMXc9EJDcNs9CCcfHuKaEGtH1kFCKTSaA8oFMqZbLb/dDrwPCFW239eBZOGlGox7cW@nongnu.org","X-Gm-Message-State":"AOJu0Yx9JXzOTYsBICCXpOPw02rY7JLGErluqPF7DhuBZSJTawu+19b8\n v3f/IbItJgaFQuXazKZOWiBBiuA9m7CL89y/nQcswfowuQ0DBGclPxjN1i6GbXVTX+etmZ3Iyvc\n g6PQinM6UnrsV4WTlcm0UHbwze/9QgQY=","X-Gm-Gg":"AeBDiev0Ldr5PyHI5UdZ84Ko5nJHWVxfRrIwtQqYxOUjIhc6Cdah8qLgumLl+UQ08Ub\n uiyuj9uNjyCS5aQnjZPkXFP7BcAyjF/5c845nQ3THRP/Y1ksFreAkOXBRddAsZT+B7jjXUf1JRB\n E0nRywU1DWwmvQmAeh6U1F0NCrLN4uXm7TUWvSeafhQzGMMCVdvQItrDYvoqCGUDjnNCM/ZfGcc\n M6SCZIojbAkyHHGubUro9P8ZyYJGM9zAgHMFNrkkateO1SKJDT4TvEFC3evbkigUuQRl3igtXdk\n yo+Znt0Y1k/IcKh5EUNIveB4iff3EDu7IOEo1/O4nSz+ZZfTAw4=","X-Received":"by 2002:a19:550f:0:b0:5a4:113a:aef7 with SMTP id\n 2adb3069b0e04-5a415521f22mr138692e87.17.1776366900751; Thu, 16 Apr 2026\n 12:15:00 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>\n \n ","In-Reply-To":"","From":"Gyorgy Tamasi ","Date":"Thu, 16 Apr 2026 21:14:48 +0200","X-Gm-Features":"AQROBzAkK2oiddFn99clcFcv7iZSkhMROcEnWMkB4gBgnfXZLqlnmtFCdE8Txeo","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Peter Maydell ","Cc":"Huacai Chen ,\n Pierrick Bouvier ,\n laurent@vivier.eu, qemu-devel@nongnu.org,\n Richard Henderson ,\n bibo mao ,\n xianglai li , pierrick.bouvier@posteo.net,\n Pierrick Bouvier ,\n gaosong ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=2a00:1450:4864:20::132;\n envelope-from=gyorgy.tamasi@gmail.com; helo=mail-lf1-x132.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3681539,"web_url":"http://patchwork.ozlabs.org/comment/3681539/","msgid":"<23e33b6a-acca-4e01-aa3e-d702aa45ea4c@gmx.de>","list_archive_url":null,"date":"2026-04-23T15:36:21","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":1115,"url":"http://patchwork.ozlabs.org/api/people/1115/","name":"Helge Deller","email":"deller@gmx.de"},"content":"On 4/16/26 21:14, Gyorgy Tamasi wrote:\n> Hi Peter,\n> \n> Your analysis cleared some things related to this older changeset:\n> https://github.com/qemu/qemu/commit/c52e405968341b1d10c618f23bdbb841e39f9255\n> \n> Before this syscall-NR 79 & 80 (newfstatat & fstat) was not enumerated\n> in the old/deleted (non-generated)\n> linux-user/loongarch64/syscall_nr.h‎...but these appeared again in the\n> newly created linux-user/loongarch64/syscall.tbl‎.\n> \n> I can recall that I was getting \"Unknown syscall\" messages for 79 &\n> 80, when I tried to run qemu-user 8.x.x even with the simplest ABI 1.0\n> executable, because even the shared-lib loading phase failed on these\n> missing syscalls 79 & 80 (used by the old glibc env of that ABI 1.0\n> exe). So in the case of that older qemu-user 8.x.x it was obvious that\n> it is not compatible with ABI 1.0.\n\nI've applied this patch to the linux-user for-next git tree at:\nhttps://gitlab.com/hdeller/qemu/-/commits/linux-user-next?ref_type=heads\n\nI've added the comments from Peter to the commit message.\nPeter suggested to adjust the commit message.\nGyorgy: If you want to resend the patch with a rephrased commit message, I'm happy to take it.\n\nFurthermore: Do we want to backport this patch to earlier qemu releases?\n\nHelge\n\n> \n> Thanks,\n> -tgy\n> \n> On Thu, Apr 16, 2026 at 2:28 PM gaosong wrote:\n>>\n>> 在 2026/4/16 上午12:06, Gyorgy Tamasi 写道:\n>>> Hi,\n>>>\n>>> This is a very simple change within a broader and more complex logical\n>>> context. It has an important property: it targets a single specific\n>>> QEMU configuration (LOONGARCH64) and has no possible side effects for\n>>> other configurations. Additionally, it can only have a positive effect\n>>> in any context (in any QEMU fork) when the modified code is\n>>> executed—even in non-standard or unexpected scenarios, such as\n>>> attempting to run an ABI 1.0 binary using a qemu-user-loongarch64\n>>> build intended for ABI 2.0. In such cases, if the limited (non-ABI\n>>> 2.0–specific) feature set of the ABI 1.0 application happens to allow\n>>> execution, this change still behaves safely. In this sense, it follows\n>>> a fundamental principle of software bug fixing (and medicine): primum\n>>> non nocere (“first, do no harm”). 🙂\n>>>\n>>> I understand that we are currently in the middle of an important\n>>> transition period, during which even traditionally “Old World” (ABI\n>>> 1.0–dependent) LoongArch64 Linux distributions are releasing their\n>>> “New World” (ABI 2.0–specific) versions.\n>>>\n>>> I do not feel qualified to estimate the duration of the next phase of\n>>> this transition, namely the replacement of ABI 1.0 OS installations\n>>> with ABI 2.0 versions in the end-user base. If a company plans to\n>>> release something for LoongArch64 now, and its goal is to make it\n>>> available to as many users as possible, building for ABI 2.0—and\n>>> optionally also for ABI 1.0—may still be a reasonable choice (provided\n>>> a sufficiently large number of users are still on ABI 1.0 systems\n>>> before they upgrade).\n>>>\n>>> My (admittedly very specific) personal perspective: I do not yet have\n>>> access to real LoongArch64 hardware, so I have been testing both ABI\n>>> 2.0 and ABI 1.0 LA64 binaries using different qemu-user versions (even\n>>> if this is not a typical use case). Since I have already applied this\n>>> modification in my own qemu-user builds, the issue no longer affects\n>>> me. Therefore, I can accept that this fix may not be integrated into\n>>> the official QEMU branches (given that it concerns the now phasing-out\n>>> ABI 1.0). The decision is beyond my scope.\n>> Hi,\n>>\n>> Thank you for your explanation. QEMU 11.0 is currently in the RC4 stage,\n>> so I believe we can merge this patch in the next cycle.\n>> Thank you again for your contribution to QEMU.\n>>\n>>\n>> Thanks.\n>> Song Gao\n>>> Best regards,\n>>> -tgy\n>>>\n>>>\n>>> On Mon, Apr 13, 2026 at 5:04 AM gaosong wrote:\n>>>> 在 2026/4/11 下午6:39, Gyorgy Tamasi 写道:\n>>>>>>> This changeset was the last mod of syscall_defs.h - but it still\n>>>>>>> incorrectly modifies the condition of struct target_stat64 usage:\n>>>>>>> (~ \"Add Loongarch64 old ABI support\")\n>>>>>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n>>>>>>> (line 2006)\n>>>>>>> -----\n>>>>>>> -#if !defined(TARGET_RISCV64)\n>>>>>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>>>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n>>>>>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n>>>>>> Huacai\n>>>>> But here the added \"|| defined(TARGET_LOONGARCH64)\" part doesn't fix\n>>>>> that affected bug similar to RISCV[32] vs. RISCV64...you need \"&&\n>>>>> !defined(TARGET_LOONGARCH64)\" here to create an effect for\n>>>>> TARGET_LOONGARCH64 similar to the proper solution for TARGET_RISCV64\n>>>>> (~ disable the use of this struct target_stat64 with 32bit sec/nsec\n>>>>> fields for a glibc environment where 64bit sec/nsecs are used - the\n>>>>> default struct target_stat is perfect for these 64bit envs, do not let\n>>>>> TARGET_HAS_STRUCT_STAT64 to be defined). [This 2nd embedded \"||\n>>>>> defined(TARGET_LOONGARCH64)\" within an other encapsulating \"||\n>>>>> defined(TARGET_LOONGARCH64)\" #elif-section is effectively a no-op here\n>>>>> (the 2nd is always true, if the encapsulating 1st was true)...it does\n>>>>> not effectively change the behaviour of its conditional\n>>>>> code-fragment-body in the actual context...comparing to the original\n>>>>> \"#if !defined(TARGET_RISCV64)\" full-line.]\n>>>>>\n>>>>> How the contexts of LoongArch64 ABI1.0 vs. ABI2.0 are linked to this\n>>>>> issue (related to an optional code-path in qemu/linux-user/syscall.c)?\n>>>>> The answer:\n>>>>> The existence of this bug does not directly depend on or linked to any\n>>>>> difference of core features of LA64's ABI1.0 vs. ABI2.0.\n>>>>> The difference in behaviour of ABI1.0 and ABI2.0 environments related\n>>>>> to this qemu-code-part here strictly depends on the behaviour of\n>>>>> specific glibc versions used by those LA64 ABI1.0 and ABI2.0\n>>>>> environments.\n>>>>>\n>>>>> In the ABI1.0 env of glibc-2.28-7cdc44d5a1 used by Loongson's gcc 8.3\n>>>>> rc1.6 a stat-like call (filling up a struct stat instance) IS NOT\n>>>>> always routed via the statx syscall, newfstatat can be used\n>>>>> instead!...and the processing of this newfstatat triggers the usage of\n>>>>> the problematic code-path in qemu/linux-user/syscall.c having this\n>>>>> bug, related to the host_to_target_stat64() function, where this code\n>>>>> fragment prefers to use struct target_stat64 (instead of struct\n>>>>> target_stat), if its use is enabled by\n>>>>> defined(TARGET_HAS_STRUCT_STAT64):\n>>>>> (~ around line 7975 in the 10.2.2 source)\n>>>>> #if defined(TARGET_HAS_STRUCT_STAT64)\n>>>>> struct target_stat64 *target_st;\n>>>>> #else\n>>>>> struct target_stat *target_st;\n>>>>> #endif\n>>>>>\n>>>>> While in the ABI2.0 env of glibc of this gcc\n>>>>> https://github.com/loongson/build-tools/releases/download/2025.08.08/x86_64-cross-tools-loongarch64-binutils_2.45-gcc_15.1.0-glibc_2.42.tar.xz\n>>>>> from https://github.com/loongson/build-tools (glibc:\n>>>>> https://ftp.gnu.org/gnu/glibc/glibc-2.42.tar.xz) ALL stat-like calls\n>>>>> ARE ROUTED via the statx syscall, so the problematic code path of\n>>>>> host_to_target_stat64() IS NOT used/triggered at all (and processing\n>>>>> path of the statx syscall in linux-user/syscall.c is correct). This\n>>>>> behaviour of glibc-2.42 can be determined by these definitions in\n>>>>> glibc-2.42/sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h:\n>>>>> -----\n>>>>> /* To avoid the messy usage of the fstat, newfstatat, and statx system calls, we\n>>>>> only use statx. */\n>>>>> #undef __NR_fstat\n>>>>> #undef __NR_newfstatat\n>>>>> -----\n>>>>>\n>>>>> -tgy\n>>>> Hi,\n>>>>\n>>>> Thank you for your explanation.\n>>>>\n>>>> I confirm that the same issue exists in the 9.2-tcg-old branch, and you have clearly identified the root cause of the problem.\n>>>> There is no doubt that the patch itself is fine, but what confuses me is that you attempted to run (ABI 1.0.0) using QEMU (ABI 2.0),\n>>>> which led to the misconception that QEMU (2.0) is compatible with 1.0, when in fact QEMU has never been compatible with 1.0.\n>>>> As far as I understand, the differences between the ABI 2.0 and ABI 1.0 environments should be quite significant.\n>>>>\n>>>> Therefore, I am unsure whether we should accept this patch.\n>>>> Should we submit this patch to the 9.2-tcg-0ld branch?\n>>>> Or should you consider discontinuing support for ABI 1.0? To my knowledge, ABI 2.0 has now become the mainstream standard.\n>>>>\n>>>> Thanks.\n>>>> Song Gao\n>>>>\n>>>>> On Sat, Apr 11, 2026 at 10:24 AM Huacai Chen wrote:\n>>>>>> On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi wrote:\n>>>>>>> Hi,\n>>>>>>>\n>>>>>>> Thanks for the link of this separate Loongson-maintained 9.2-tcg-old\n>>>>>>> branch - intended for use specifically with ABI 1.0 code.\n>>>>>>>\n>>>>>>> This separate branch still contains the same bug (in the context of\n>>>>>>> the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where\n>>>>>>> fstatat syscall can be used by glibc, and it can trigger the usage of\n>>>>>>> the related erroneous data-conversion workflow based on struct\n>>>>>>> target_stat64 with 4byte sec/nsec fields):\n>>>>>>>\n>>>>>>> This changeset was the last mod of syscall_defs.h - but it still\n>>>>>>> incorrectly modifies the condition of struct target_stat64 usage:\n>>>>>>> (~ \"Add Loongarch64 old ABI support\")\n>>>>>>> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99\n>>>>>>> (line 2006)\n>>>>>>> -----\n>>>>>>> -#if !defined(TARGET_RISCV64)\n>>>>>>> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>>>> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed\n>>>>>> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.\n>>>>>>\n>>>>>> Huacai\n>>>>>>\n>>>>>>> -----\n>>>>>>>\n>>>>>>> This is the broader context in this 9.2-tcg-old original version:\n>>>>>>> Here the 2nd embedded \"|| defined(TARGET_LOONGARCH64)\" normally a\n>>>>>>> no-op: always true/false if the 1st \"|| defined(TARGET_LOONGARCH64)\"\n>>>>>>> is true/false.\n>>>>>>> -----\n>>>>>>> #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \\\n>>>>>>> || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \\\n>>>>>>> defined(TARGET_LOONGARCH64)\n>>>>>>> /* These are the asm-generic versions of the stat and stat64 structures */\n>>>>>>>\n>>>>>>> #define TARGET_STAT_HAVE_NSEC\n>>>>>>> struct target_stat {\n>>>>>>> ...\n>>>>>>> };\n>>>>>>>\n>>>>>>> #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>>>>> #define TARGET_HAS_STRUCT_STAT64\n>>>>>>> struct target_stat64 {\n>>>>>>> ...\n>>>>>>> };\n>>>>>>> #endif\n>>>>>>>\n>>>>>>> #elif defined(TARGET_HPPA)\n>>>>>>> -----\n>>>>>>>\n>>>>>>> The correct fix is the same here (~ disable the use of this struct\n>>>>>>> target_stat64 - instead of explicitly enabling it for\n>>>>>>> TARGET_LOONGARCH64 with the \"|| defined(...)\" part):\n>>>>>>> -----\n>>>>>>> ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h\n>>>>>>> --- syscall_defs.h.ori 2026-04-10 20:53:34.639034304 +0200\n>>>>>>> +++ syscall_defs.h 2026-04-10 20:55:12.219347804 +0200\n>>>>>>> @@ -2003,7 +2003,7 @@\n>>>>>>> abi_uint __unused5;\n>>>>>>> };\n>>>>>>>\n>>>>>>> -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)\n>>>>>>> +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)\n>>>>>>> #define TARGET_HAS_STRUCT_STAT64\n>>>>>>> struct target_stat64 {\n>>>>>>> abi_ullong st_dev;\n>>>>>>> -----\n>>>>>>>\n>>>>>>> The same test-scenario of\n>>>>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used\n>>>>>>> [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old\n>>>>>>> toolset] to show exactly the same bad & good test results - without &\n>>>>>>> with this mod.\n>>>>>>>\n>>>>>>> Just a personal experience based side-note on ABI1.0 compatibility\n>>>>>>> with mainline qemu (~10.2.2):\n>>>>>>> I'm working on porting a quite large code-base (a commercial OCR &\n>>>>>>> document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and\n>>>>>>> I'm trying to check correctness of my actual builds using the\n>>>>>>> regression-test package of this codebase. It runs quite complex\n>>>>>>> workflows of general CLI code. I accept that this is not a\n>>>>>>> comprehensive test with all of the edge cases or touching every\n>>>>>>> special areas (like signal handling) of compatibility of ABI1.0 and\n>>>>>>> mainline qemu, but...the ABI1.0 version of this test-code seems to be\n>>>>>>> able to run with mainline qemu-user 10.2.2.\n>>>>>>>\n>>>>>>> Best regards,\n>>>>>>> -tgy\n>>>>>>>\n>>>>>>> On Fri, Apr 10, 2026 at 11:37 AM gaosong wrote:\n>>>>>>>> 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:\n>>>>>>>>> Tested-by: Gyorgy Tamasi \n>>>>>>>>>\n>>>>>>>>> Additional independent testing (bug + fix cases) is documented here -\n>>>>>>>>> see comments by sourav/@kishu279:\n>>>>>>>>> https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>>>>>>>> Hi.\n>>>>>>>> Please note that QEMU is not compatible with ABI 1.0.\n>>>>>>>>\n>>>>>>>> If you absolutely must use ABI 1.0, the branch below is the version we use.\n>>>>>>>> https://github.com/loongson/qemu/commits/9.2-tcg-old/\n>>>>>>>>\n>>>>>>>> However, this branch is quite far from the mainline.\n>>>>>>>> The QEMU mainline follows the kernel mainline, and\n>>>>>>>> I believe this is the case for other architectures as well.\n>>>>>>>>\n>>>>>>>> Thanks.\n>>>>>>>> Song Gao\n>>>>>>>>> On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier\n>>>>>>>>> wrote:\n>>>>>>>>>> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:\n>>>>>>>>>>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and\n>>>>>>>>>>> TARGET_LOONGARCH64 are defined!) we can not use the struct\n>>>>>>>>>>> target_stat64 for data-transfer, since this struct target_stat64 is\n>>>>>>>>>>> defined for 32bit environments with its int-sized (4byte) st_*time\n>>>>>>>>>>> sec/nsec components.\n>>>>>>>>>>> The user side compiler headers of the LoongArch64 env uses long-sized\n>>>>>>>>>>> (8byte) st_*time sec/nsec components.\n>>>>>>>>>>>\n>>>>>>>>>>> (This is similar to the case of 32bit vs. 64bit RISCV: the original\n>>>>>>>>>>> code does not use struct target_stat64 in 64bit RISCV env, when both\n>>>>>>>>>>> TARGET_RISCV and TARGET_RISCV64 are defined.)\n>>>>>>>>>>>\n>>>>>>>>>>> This fix is important for LoongArch64 ABI1.0, where stat() is using an\n>>>>>>>>>>> fstatat syscall with this struct target_stat64, if its usage is\n>>>>>>>>>>> enabled.\n>>>>>>>>>>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this\n>>>>>>>>>>> problematic struct target_stat64 is not used, struct statx is correct\n>>>>>>>>>>> in the LoongArch64 env.)\n>>>>>>>>>>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371\n>>>>>>>>>>>\n>>>>>>>>>>> Signed-off-by: Gyorgy Tamasi \n>>>>>>>>>>> ---\n>>>>>>>>>>> linux-user/syscall_defs.h | 2 +-\n>>>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>>>>>>>>>>\n>>>>>>>>>> Reviewed-by: Pierrick Bouvier \n>>\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=gmx.de header.i=deller@gmx.de header.a=rsa-sha256\n header.s=s31663417 header.b=LVa/FJTL;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1gFG4R3tz1y2d\n\tfor ; Fri, 24 Apr 2026 01:37:06 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wFw6l-0002ea-D6; Thu, 23 Apr 2026 11:36:55 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1wFw6X-0002dU-1F\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 11:36:39 -0400","from mout.gmx.net ([212.227.17.22])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1wFw6T-0000gC-Og\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 11:36:36 -0400","from client.hidden.invalid by mail.gmx.net (mrgmx105\n [212.227.17.168]) with ESMTPSA (Nemesis) id 1M5QFB-1wHJ9D1Fv3-00HGr1; Thu, 23\n Apr 2026 17:36:26 +0200"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;\n s=s31663417; t=1776958586; x=1777563386; i=deller@gmx.de;\n bh=ovRjcfEclcOo6JzpkPA/9gQ07TevjWrICsG8ojv1+R8=;\n h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:\n References:From:In-Reply-To:Content-Type:\n Content-Transfer-Encoding:cc:content-transfer-encoding:\n content-type:date:from:message-id:mime-version:reply-to:subject:\n to;\n b=LVa/FJTL4vXxgiO1dROlQuzyqGcHNiB9Q23oN9e6xpzMEg+vsGvj/iqCwuS5sWC7\n OtKuqxmkQ1Xu1ym+Z0SDBjHVMSHJyaXucqOMWwuEkpCyyMGg8z/Ca1i/qyfWbsz3P\n UjhitqWeOrKcp+lt+XcEdkhR0lj0dimMFatokfVQGF3kNwWLIWsrGzCUcJMbpO9Zj\n hrlS/OxiQ8t0n4PDQs11b/7EtYr3AtaUu4KyyNEWrKhKtQIgqat1nTso7lGRcH6dg\n hGw1PD56KEZyptdw+QQh1yjKFKJHIvtztr5Cfm78s/Yec/mqfp1Tv/jyq2z15phZ4\n 4THaLNkGzVeIYb4+Fw==","X-UI-Sender-Class":"724b4f7f-cbec-4199-ad4e-598c01a50d3a","Message-ID":"<23e33b6a-acca-4e01-aa3e-d702aa45ea4c@gmx.de>","Date":"Thu, 23 Apr 2026 17:36:21 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Gyorgy Tamasi ,\n Peter Maydell ","Cc":"Huacai Chen ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Richard Henderson ,\n bibo mao , xianglai li ,\n pierrick.bouvier@posteo.net,\n Pierrick Bouvier ,\n gaosong ","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>\n \n \n ","Content-Language":"en-US","From":"Helge Deller ","Autocrypt":"addr=deller@gmx.de; keydata=\n xsFNBF3Ia3MBEAD3nmWzMgQByYAWnb9cNqspnkb2GLVKzhoH2QD4eRpyDLA/3smlClbeKkWT\n HLnjgkbPFDmcmCz5V0Wv1mKYRClAHPCIBIJgyICqqUZo2qGmKstUx3pFAiztlXBANpRECgwJ\n r+8w6mkccOM9GhoPU0vMaD/UVJcJQzvrxVHO8EHS36aUkjKd6cOpdVbCt3qx8cEhCmaFEO6u\n CL+k5AZQoABbFQEBocZE1/lSYzaHkcHrjn4cQjc3CffXnUVYwlo8EYOtAHgMDC39s9a7S90L\n 69l6G73lYBD/Br5lnDPlG6dKfGFZZpQ1h8/x+Qz366Ojfq9MuuRJg7ZQpe6foiOtqwKym/zV\n dVvSdOOc5sHSpfwu5+BVAAyBd6hw4NddlAQUjHSRs3zJ9OfrEx2d3mIfXZ7+pMhZ7qX0Axlq\n Lq+B5cfLpzkPAgKn11tfXFxP+hcPHIts0bnDz4EEp+HraW+oRCH2m57Y9zhcJTOJaLw4YpTY\n GRUlF076vZ2Hz/xMEvIJddRGId7UXZgH9a32NDf+BUjWEZvFt1wFSW1r7zb7oGCwZMy2LI/G\n aHQv/N0NeFMd28z+deyxd0k1CGefHJuJcOJDVtcE1rGQ43aDhWSpXvXKDj42vFD2We6uIo9D\n 1VNre2+uAxFzqqf026H6cH8hin9Vnx7p3uq3Dka/Y/qmRFnKVQARAQABzRxIZWxnZSBEZWxs\n ZXIgPGRlbGxlckBnbXguZGU+wsGRBBMBCAA7AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA\n FiEERUSCKCzZENvvPSX4Pl89BKeiRgMFAl3J1zsCGQEACgkQPl89BKeiRgNK7xAAg6kJTPje\n uBm9PJTUxXaoaLJFXbYdSPfXhqX/BI9Xi2VzhwC2nSmizdFbeobQBTtRIz5LPhjk95t11q0s\n uP5htzNISPpwxiYZGKrNnXfcPlziI2bUtlz4ke34cLK6MIl1kbS0/kJBxhiXyvyTWk2JmkMi\n REjR84lCMAoJd1OM9XGFOg94BT5aLlEKFcld9qj7B4UFpma8RbRUpUWdo0omAEgrnhaKJwV8\n qt0ULaF/kyP5qbI8iA2PAvIjq73dA4LNKdMFPG7Rw8yITQ1Vi0DlDgDT2RLvKxEQC0o3C6O4\n iQq7qamsThLK0JSDRdLDnq6Phv+Yahd7sDMYuk3gIdoyczRkXzncWAYq7XTWl7nZYBVXG1D8\n gkdclsnHzEKpTQIzn/rGyZshsjL4pxVUIpw/vdfx8oNRLKj7iduf11g2kFP71e9v2PP94ik3\n Xi9oszP+fP770J0B8QM8w745BrcQm41SsILjArK+5mMHrYhM4ZFN7aipK3UXDNs3vjN+t0zi\n qErzlrxXtsX4J6nqjs/mF9frVkpv7OTAzj7pjFHv0Bu8pRm4AyW6Y5/H6jOup6nkJdP/AFDu\n 5ImdlA0jhr3iLk9s9WnjBUHyMYu+HD7qR3yhX6uWxg2oB2FWVMRLXbPEt2hRGq09rVQS7DBy\n dbZgPwou7pD8MTfQhGmDJFKm2jvOwU0EXchrcwEQAOsDQjdtPeaRt8EP2pc8tG+g9eiiX9Sh\n rX87SLSeKF6uHpEJ3VbhafIU6A7hy7RcIJnQz0hEUdXjH774B8YD3JKnAtfAyuIU2/rOGa/v\n UN4BY6U6TVIOv9piVQByBthGQh4YHhePSKtPzK9Pv/6rd8H3IWnJK/dXiUDQllkedrENXrZp\n eLUjhyp94ooo9XqRl44YqlsrSUh+BzW7wqwfmu26UjmAzIZYVCPCq5IjD96QrhLf6naY6En3\n ++tqCAWPkqKvWfRdXPOz4GK08uhcBp3jZHTVkcbo5qahVpv8Y8mzOvSIAxnIjb+cklVxjyY9\n dVlrhfKiK5L+zA2fWUreVBqLs1SjfHm5OGuQ2qqzVcMYJGH/uisJn22VXB1c48yYyGv2HUN5\n lC1JHQUV9734I5cczA2Gfo27nTHy3zANj4hy+s/q1adzvn7hMokU7OehwKrNXafFfwWVK3OG\n 1dSjWtgIv5KJi1XZk5TV6JlPZSqj4D8pUwIx3KSp0cD7xTEZATRfc47Yc+cyKcXG034tNEAc\n xZNTR1kMi9njdxc1wzM9T6pspTtA0vuD3ee94Dg+nDrH1As24uwfFLguiILPzpl0kLaPYYgB\n wumlL2nGcB6RVRRFMiAS5uOTEk+sJ/tRiQwO3K8vmaECaNJRfJC7weH+jww1Dzo0f1TP6rUa\n fTBRABEBAAHCwXYEGAEIACAWIQRFRIIoLNkQ2+89Jfg+Xz0Ep6JGAwUCXchrcwIbDAAKCRA+\n Xz0Ep6JGAxtdEAC54NQMBwjUNqBNCMsh6WrwQwbg9tkJw718QHPw43gKFSxFIYzdBzD/YMPH\n l+2fFiefvmI4uNDjlyCITGSM+T6b8cA7YAKvZhzJyJSS7pRzsIKGjhk7zADL1+PJei9p9idy\n RbmFKo0dAL+ac0t/EZULHGPuIiavWLgwYLVoUEBwz86ZtEtVmDmEsj8ryWw75ZIarNDhV74s\n BdM2ffUJk3+vWe25BPcJiaZkTuFt+xt2CdbvpZv3IPrEkp9GAKof2hHdFCRKMtgxBo8Kao6p\n Ws/Vv68FusAi94ySuZT3fp1xGWWf5+1jX4ylC//w0Rj85QihTpA2MylORUNFvH0MRJx4mlFk\n XN6G+5jIIJhG46LUucQ28+VyEDNcGL3tarnkw8ngEhAbnvMJ2RTx8vGh7PssKaGzAUmNNZiG\n MB4mPKqvDZ02j1wp7vthQcOEg08z1+XHXb8ZZKST7yTVa5P89JymGE8CBGdQaAXnqYK3/yWf\n FwRDcGV6nxanxZGKEkSHHOm8jHwvQWvPP73pvuPBEPtKGLzbgd7OOcGZWtq2hNC6cRtsRdDx\n 4TAGMCz4j238m+2mdbdhRh3iBnWT5yPFfnv/2IjFAk+sdix1Mrr+LIDF++kiekeq0yUpDdc4\n ExBy2xf6dd+tuFFBp3/VDN4U0UfG4QJ2fg19zE5Z8dS4jGIbLg==","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"quoted-printable","X-Provags-ID":"V03:K1:2qIVZPsgEVMohSmP0oM7qSMynv2niWm9d2lUKoJ2FEV89CtUMgf\n ixvEKAldUWu2tGIQKOrxGuLBBH7SiH6jXwtFozEAPeHbbiL7uoZ6EKorDfTrKkt6fyq3Kem\n XEPMpWBvhxami/S7P5sPbgZevH1pAYI8u9yMg8nnsE656Vh8ovExyK2Nafwe/vDQPxPppg2\n on17+8P4WFLC/INTEM3ZA==","UI-OutboundReport":"notjunk:1;M01:P0:Dg3NVOorGEg=;XzMoJMYpRqJFyv18Bb9rgeX5ZRM\n EHR0jpfkLsTQG3J29UTbk1iYf3V2uEEWm6hnS7KYHQVM+JpjgL5QWX95/dPAnbofeglO9QCu9\n fOhB2FOm+qyJyvLSASxRqPjahpxf04LbVasdnHVZUdUHl48kDyXpvOVjK0p9W3lfOJJ40sYaD\n 8zEzzPhITDG+RGH3AosuArXGrFrod1Wi9Sp9cxSiCeVfF7wWs3mukgqzA0FBm0pTLIMYG4g16\n vR6t9P746iYRYHiZVXxFbM7/ze9UgIaNYfcF60uXjYv+TjFi388w5Gnv42UO8hZ5aJyGQq4jG\n swYLmDb46xT2C3uvjOlmnsp1oOoPhezTbrTZvq8B71qyk7PhdQ46wUhbayVGHOJBHMGj+zACs\n lrihKBR8n933ridS3apucsNo2JZPvjJwUaskfLyobciNpIZUXSl/VketdoCoV/w0DI+cp5qwb\n lP3VJtotYO6lr9iC4+kdYsQ3iHsu2TxGjTi9HyqjvNTuOqqGspvmLUQG2MCT7VGgPDSR/lutF\n 8EXy6dnLB0VuAQiUoapvGe9b7GgUq6TKJbl7k9rG2Zgt/l6vMyLv0ZkGLG6B2Flg+kY/Ffinp\n DSmBHvmo8yRECY+L1pbkbKQc4gO8Ub3aA/hbuoxYwvzcV6y8CUYSHbnRI0dwRO4vTuaXqvjTW\n YQ+oil/0eSEySW57B8qvjA1ga7TuJq3lqPdrugtK3iPr09SsGf773pOwY4ZfqgXExVT18Xlr5\n rvYJF/GbV4rjwpH9DRxdPK36EOfwXv0aQrJFxbVwxa/iOFN+SXkdVY2CYyCcUNcyWM9nyF/c7\n 1aIsIiQAzjQEng+c3G7ePcPDe3034TNEcAznVUE9VRJUd+Dj6Wm+hCZi0dUS2Q3xf0hQBGhO/\n JUHvT8d6KAD4qCXSqi1aahtq4oCuxsbxes1mmMvloFV68JdLC0/GdTVH7DHWfOWSi9B8lBWaw\n yZpOVOA2gRlouTN7E9omt/C2YkFAH7e5T4ykohBo6uMQzMJV0Ln4kMlg4nCQh/nVHFMAtMOE2\n 5lmD7BH8OQlymtJXK4ZuKvWYWjTw8Oia8Z/6Qe7aKKjzYepOUh+ZLvhV6DISvVgLo1CUCdeoi\n vhkDD1n5QFw+/qLu5EYjcPOr6AnZG+EEl1UsDbCzl5SvfIIRFgsTzH0PQO65kUDa4Ac2dC32B\n VFY1kL2/4n1xHbREvDfqAWNQ+2pamxEjsfWmWmuWLuZ54BqEm9IcdGACeE52K5AF7nkskK84N\n nYQ+yYhXHda+lWXZzNwjaiZHiKRSvOH08fbCA1bgldoAm4O6gyDDn6Dc6cm+nIvkQW03pQE5p\n XOq19eg2JloFXRQAdL1/gD9g+qxAbk35aFASoZBnGfaQ/pS/tKVcIqG/2cMByBEvbPrSXcCXr\n wttrSTGxfPXIEzJt7lGminw9NhNJhlt6/ZgQuknYX8jhOIVsAWqM+rkMmaSvxJArQGp2C2DJW\n y4b0v1UMZPrL3FJzV+01iUNCAOWenMPFeRKWUw/dqojJlSUcuDcaH4P56S9KCqiu+gquAce6X\n oFauhFShuVE2xB0uKaCY9THdWw/UYnYmDYJb28lL/t4qgdXsdEpAItegyVhi9zI8JDJPK6VTy\n 5yZAEbS8s7loZT/K++kFs2Xo370jGFI3EA2KEZzarr9fzLnkCzmx86a1VYr6IprXL9NAWYspJ\n 4Ln4hhjahFP/vMAJEgx8rmFsDCuC4I7PULDBKeKT7mUS2QWLR7l6GXAvqTveaCQbOQoE+aXs+\n 2LmrVZBW9x719EAc5cXwduqW/PfCTq7yJWM3B5U8OLGbJrBMVnxBh28TlmhFSFH3q5LUDMIN8\n UPoF4A1qFW5w/hTcPi/lair2eKNAk+MiH5EfPdruMazvrMp+aSVp7otoBSdVrmE+K2lmDU7eV\n uXyAinC50DNDZuF7Ik+CWvH26Gi0W9lbYBtHomHzdGkGQm5j6jgJRkS9tz/l50yzwX3rzreRO\n G1cHS3Q8MJRwNVUjEQJ8s+2iRpHxFKZaxDWjD6Qk6bDdyskbIyr6VxnRierecOfpAq+2qgtIU\n nJ6OI97FuxTKFBAFNNbBBj0Vim1cu6tTrusFJ+z4zgpBlrMmgq+LWq1+e0qxFMkrQOBDTasI+\n 5v3JYqgjJf6tuMJRozjBlRHxmZjwCK961hAJN9VjwIgA+OnyUx5v8+lZe5grhLaoQukFTvz2l\n 33asbf3/L1DYS5S6oKkCOkIimBRT5l1rWmP2Jsx16GOheRmA/j9/nS7CaZRKLMmEQJg/ahBXq\n 8UCKlZBbgjbzU5uE5lUA2vCZoLL9WVzoMztd2GjR8PzFpSFjmJhP2r+S/CAcvO10erhtiqRlC\n Lfw0Hy6KlAsd1nkPpJevBW8tV6pon0kHM9WuKXBHlb2JH3f0l8LEulW1+fWxeu1bvj/Abwsk5\n +Was4mFn8LKbcN/VOGTt87yZ4gWRjoeBSmvG65h6fva4eARmy5mnEjUWYxH+MdAb9rVM6ppf+\n vm02PlqhWZkt9CB7hghNOFxAosGO0w1gCZw7HShxdFR70DZrege4AyGyiN4fNuj/202Zuh3d1\n SUSS5MS9xo4j1zzTXOnHIFJSeo0PSkz6+lmLSs56f23dNKLLY7WTMW9gu6FPx3kB0cjjFl3l2\n DmIrL1fiDFAlK7+FpUcBbl13QftCJ7jRM/bRa9bZDGzL0JG6wYrWnIa8FuNeXoqTGiEDIe1Pa\n ZW2Wa7Qu5znhPaY/U85hwXfiAulttcfwUSy+ElUeQmuTB/jAnXdSJd/pacmB6Qn64dTFHMZOu\n 9rF5FJhom0hbYwTIphB6Nbphs7LLA/abGeDR4x6QuBUka7lbtZOAJP9PhwxUVEk31Tn6wrwkO\n UfkuE7kQqLAKXHj/SWxXkLtdjMp2T1xCA+xykJxXV+mBnah4z3M8qT//7fODJ24xvojTQiWlg\n mRv5XWH+5wU3VM/YKUALvXwSelsAtKWfSb/iO4f3BcJPurbQK9TNCIvt+N6Rtqkj5cYbqOz0y\n jTgm4g8h+GeiwhLE1a8p01UxOi9d5gd3uSadbTtRQ5kVMgqfvOGZ0SvNh38drDlxPdfWOFmt5\n gbS8CtZOU6CpOXJM/PuCF/deysEO9Mm0M1VZPLroigkAPmiyzTmMiD5RcTRzsSmwmaFQ/zoGQ\n kHe7dZzihEBxWiHv7Gn2seQn788AHx7vH0TJFqNLuTmtXcRD2G9BYH4kOswcoPcdp/YrOWYQh\n SucEPVEUPTDQtnEFiPciGj7aCgDf3VkMaGDiznvOGAnvr0KcN7jIlE0kjFM9/eJBgLgUqJyrC\n oWm5AoaOlzoNCVhi7u9+pB3TW/PTzW3+w8aNz/CqiJNb5ncwRZHqqvIVDgfyqSVKOHLX7oD18\n nZynY6IuZL/jSgnyQnGr7ODl0RPjJXG/xdKKhRy+Xk1avyB4/pwUj7B8iRsSH5T8WygHMKmOb\n S2dZDI6ECcOGiyHM9A8WL+2rJ5MNONGMDjDB3gFaEDHO+rdhezAKDzsD9BJ6jN/xDKzPPiklW\n vFEDNsJcLUbBhefhdV9iDSgiWWWbwiCdbqorosFj6NdHNalydBYjgxWlUcgIZWEaGgCKU5m6Q\n Ps47YL56gq5m0oLP+owpiH+59965wpfkOVinvewxIG0dSyZFr0LiaBV5sA2PIvGvXqR8A/JDB\n 4c5nTKLfuCmR/4FZPNvHW2qHqNVtZSrGUmMZR9VHS8SVBZn4C+Ob+4NA3gb6GVDCOcv7qs+Np\n HG7ZfEsTgxRmbiAPas1KmtB7pBeuqdZmyAicCMtEN1nuiTTpCR5wO5NYu6ad4wk7dZwItpE1U\n dvQ5jS8fpL/IrK4jD7qeliWlOWoW4JjCczyOfyzprAZS73tqQx3Bw9pJZ/khDIBTnp1iy+MOr\n AYeQxMB1a27jBuVArpqT86qf0rFOi0ZZfTOp0EO/vQmCJitD3BML5uSqYqP1tzyXpFIu2ZGP4\n Jv9cDAjqvr32G+yWaF/BnIFgAg+jB2nNLpM3vh4L0aSoXw38RY36qdtfj7g7iG2k7ZatBo3kt\n 5DlDtgimPPAIXiD8Lj5Lmq3HIPWeKxjXR/vz+oofyecVRfDvGDFASUumZVJja8anY2vYlKhJB\n NHzsWDbGB9svLomke8lSWr/4yB17359o2dNvoYdnehTA/2hL6V2SYPFT1zLOXRNy5ohA9O3M1\n 4ofz/dmhnDoPhuieuYAm33kyOkdCDt01UP1vUpz7UXKlMi4lEbT0PDd8Nd7hpvl1+mRHWyOow\n m6+LXs82Bw4dT914+L3npfapBaXzRP/V1f+zGdmZ5FlZ0Cs41CXJ6qh0brRqvER1FgeJwFiQ7\n nJaXG0lhIu41SRynFn9DlzaBJwhoFC9rCsUSRtzLXbaZ6QQPfP/FDMfo9pYVgG3NRQd2i7eM2\n q/yfDK9zDZOHBMPYnbkJdZj6vxWYZLh+bSiYgx8lGRPbq/S76m/VhV9sEyoCAQHMCFEDlX4hz\n U+gxz5Nov5aWZxrUuJj8XHRzzm46bW+B/gjeoiL7wBCBc85CZjH2S8kANyzMKiAScfT6zwHpf\n 4qA0AhLqJMZZ5AvOdE2Z0N9VV+4mIY6kwHFkXm7ejkHq/8GRVPzLezLUDg1991rWBYiOUcbmI\n DDUzxjH3Hh/sjjGTo8XDzO8xoScffHbc6DCB2w0yg1lWq3KtCpg06dXkj1Yk+3VpWYMgnXxbs\n 6GxDQV0lJz+p/M496KHlSMwoo8r6c3LFeBPdh5+fogZoAbQucDoQHDkoJX+iIp/3sg/CirwVw\n nGQbMjNHivDeL5njsMydZv60sO5vBwWeBuYnU0qu0nv6pj9AKAXYdUwF5b+D8TV9VGcLSPDm0\n QgfmtFkj596DENBX4O/bhS/P80JQR+JpYYRf4srmD+eptqRuwapSvh/o3eguUo052f/SUuRP0\n WNKwjfNOU1UteLXQ4fe5J14+wgtNz5dsh+c9TPBjcK/mK8eBYwJHB2adDCr1awOL6gnIQoHYL\n fW/mSokn9f04IoJLZlwGPbpLUzEGmkldLOysppUWoISdrBHojYFXgwuDBa9NS+uChEdqIfsv/\n XHtJ8TRbPfJGTEaUmYBkANbJoUR/mPpdvxWAQXQZBsRYDLNaOaaBCCRNHjvYuPdv1i0XKxFoy\n TdeMa5ilPD0m+FHX2lv8NIzqmgl05Gw1lshQ5Nk/fypS2gvBTC9J6Yvjk/huYZiooBrkLxLFU\n 2dy1o+4+o+cuT0u5tk9CRVo6dmLyBCiwQScONs1YUgDy/v0wLT3qo+yiQkSfO5UpBTVeQqacZ\n Ph81U17hW3A6+nJXI9VeQfG+U+//m/g93NfxKYF3OiUWHA3DJvPznSWope9GsUX30TThoM0TS\n 7ZLcq9hUiWaY9xXESvBKRktEUSCZK9LwOWkUpNsZawLgFGeTXwH3HPECawhrZfqnJzxSJ+GtB\n DLyQVeKuQH27D60sdSejO1BbqnacaG6rqSpJ2iYUJr8Zq9dga2upOvPzuGQXdV0wwFz6YrN4F\n VvYBbITmxOqDHnv1MRvUfU2URe9lzoWFzwOSOzB8G/jQ9HfmOq5iJyU5ZZ90GdS5eDB3lW3m/\n 7LxaBhRpZU503BvbuEsznX8jpw3QO5Qu81YobwXv1HSgPO3xTBM4FfLK93PfSVk+8v4C/M/ee\n rAHmYk+V6+U6FnzcgL1pGXlX4TjGsYW5krr3smy0YqpAtGjXC8xAkj/WhowGVs76GfagFQ==","Received-SPF":"pass client-ip=212.227.17.22; envelope-from=deller@gmx.de;\n helo=mout.gmx.net","X-Spam_score_int":"-27","X-Spam_score":"-2.8","X-Spam_bar":"--","X-Spam_report":"(-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3681557,"web_url":"http://patchwork.ozlabs.org/comment/3681557/","msgid":"","list_archive_url":null,"date":"2026-04-23T16:09:23","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":5111,"url":"http://patchwork.ozlabs.org/api/people/5111/","name":"Peter Maydell","email":"peter.maydell@linaro.org"},"content":"On Thu, 23 Apr 2026 at 16:36, Helge Deller wrote:\n>\n> On 4/16/26 21:14, Gyorgy Tamasi wrote:\n> > Hi Peter,\n> >\n> > Your analysis cleared some things related to this older changeset:\n> > https://github.com/qemu/qemu/commit/c52e405968341b1d10c618f23bdbb841e39f9255\n> >\n> > Before this syscall-NR 79 & 80 (newfstatat & fstat) was not enumerated\n> > in the old/deleted (non-generated)\n> > linux-user/loongarch64/syscall_nr.h‎...but these appeared again in the\n> > newly created linux-user/loongarch64/syscall.tbl‎.\n> >\n> > I can recall that I was getting \"Unknown syscall\" messages for 79 &\n> > 80, when I tried to run qemu-user 8.x.x even with the simplest ABI 1.0\n> > executable, because even the shared-lib loading phase failed on these\n> > missing syscalls 79 & 80 (used by the old glibc env of that ABI 1.0\n> > exe). So in the case of that older qemu-user 8.x.x it was obvious that\n> > it is not compatible with ABI 1.0.\n>\n> I've applied this patch to the linux-user for-next git tree at:\n> https://gitlab.com/hdeller/qemu/-/commits/linux-user-next?ref_type=heads\n>\n> I've added the comments from Peter to the commit message.\n> Peter suggested to adjust the commit message.\n> Gyorgy: If you want to resend the patch with a rephrased commit message, I'm happy to take it.\n\nThat's more conversational than we usually are for commit messages. Here's\nmy suggestion:\n\n===begin===\nlinux-user: Don't define target_stat64 struct for loongarch64\n\nThe kernel defines 'struct stat64' only if\n__BITS_PER_LONG != 64 || defined(__ARCH_WANT_STAT64).\nloongarch64 doesn't set __ARCH_WANT_STAT64, and it isn't 32-bit,\nso it won't get this struct.\n\nQEMU incorrectly does define a target_stat64 struct. However this\nisn't causing any guest-visible problems, because defining the\ntarget_stat64 struct and TARGET_HAS_STRUCT_STAT64 affects these\nsyscalls:\n TARGET_NR_stat64\n TARGET_NR_lstat64\n TARGET_NR_fstat64\n TARGET_NR_fstatat64\n TARGET_NR_newfstatat\n\nFor loongarch64 the only one of those we provide is newfstatat,\nand that is actually a separate QEMU bug, because the kernel does\nnot provide that syscall for this architecture. No real guest\ncode will be using a syscall that doesn't exist in the ABI.\n\n(Some of these syscalls are present in the loongarch64 \"ABI1.0\",\nbut that ABI was never accepted in the upstream kernel, and\nQEMU does not model that ABI, only the \"ABI2.0\".)\n\nStop defining TARGET_HAS_STRUCT_STAT64 anyway, for consistency\nwith the kernel and to avoid confusion.\n===endit===\n\nAs there's no guest-visible symptoms, I wouldn't bother cc'ing stable,\nthough it is a harmless change.\n\n-- PMM","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=Zfq83Caq;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1gzD61byz1y2d\n\tfor ; Fri, 24 Apr 2026 02:09:59 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wFwcZ-0005f8-9a; Thu, 23 Apr 2026 12:09:44 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wFwcU-0005eX-K1\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 12:09:39 -0400","from mail-yw1-x1129.google.com ([2607:f8b0:4864:20::1129])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wFwcS-00021z-RL\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 12:09:38 -0400","by mail-yw1-x1129.google.com with SMTP id\n 00721157ae682-79ea87af213so111513777b3.0\n for ; Thu, 23 Apr 2026 09:09:36 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776960576; cv=none;\n d=google.com; s=arc-20240605;\n b=kyRc7tCcm1YW059b8kZB6gxqDXV9WZGPHQOcBEG28PFrD+5B4C7vGUOxJieMFW+deS\n 3oVUXubwU5cgK2FkTEoAJT2KLBF7us1OSvca/h2gwTdRzaSD2Wu/p8YPhFp6mE143BLS\n beiAoRc37leJbG5aMWdqjk1TMBxFyGynQa7st0AlU703HQlSFSuGCQ47QsNqDd9CRw07\n B/HmwzZBx6+GAdbY4rZfo1FbyD79dNTUoneAmV4YaYBh/5QCDZxe+9MOJArdGkUr6tfz\n a5U5Fh4EnyZrhFsVL3AIb1scEh2iC2V3ExMaR/slk807T5nC+poWZ1pJhkY/W3DhK+gG\n wZrw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=Oyrb+VFTX1y1h7u/ZrXpLyEo9eukCNW5hPY4wJZwLUA=;\n fh=OYgHMKSCnXMKvNxsn8EtC8PbHXVBVskpY6rZsSCNpu8=;\n b=YB1ECm39vIFVv4zGDtmGZXoS3A3XD5cky+4MsO+9qm0HWAjaKwUKXFIil27yEoP64g\n EtKIIhwT1vT+FCwLRiCgGSbl3tIob8HcZy5u3ikUxLY7/l0DTbfiFUos0IXFgJ3s/DHK\n 8vV9HHrFUYvOmkbWN6QYw8N0LduCHEDBoF7NdgqnylnDRtQgzYvwVSKCMeboUUphrzba\n DLT58S91sXx59BxbHdbj/4tG3wTcHOpuYk+aY97DtLr32eaWgMXMCektP6QxYwShMgUU\n jnQ+d+1phENN8Zt6k2LWT8iOheGU6E7j1Ul6DEWtKn2U/jp/rG72vQahG22ybcDHjLML\n 4KDA==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776960576; x=1777565376; darn=nongnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=Oyrb+VFTX1y1h7u/ZrXpLyEo9eukCNW5hPY4wJZwLUA=;\n b=Zfq83CaqyeTMjsYzoRMg10Hd/Pc0ymyOJh6nbXCKUow5umf5ixlcWB0Rqj90/W9lYx\n 8QHGKdAzkF9vsaS55ziL5C9Itu9s3v6+xBZ0l8k2dUQR2+sloFuA3MvsKqZLnRTjAQmc\n 9U/XT+PJ5087qxBEbaPlmngPs0kZfQqjPadgPs1ku6c03jS+pYP9zJ5gfZSlScldfGDy\n VdFE+ettcTzK82abnRsAqSrCDineHwsh49KDgcSHktnO/KyX4SDzqCvq6277ZckaRVPV\n Byt8hzkt3P5ZPd91+ISml8kCcjygrdnCzEq8a2iFjSlW2SnWWS4CmYjekMacBpYqRkpe\n RkuQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776960576; x=1777565376;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=Oyrb+VFTX1y1h7u/ZrXpLyEo9eukCNW5hPY4wJZwLUA=;\n b=HVPzL4D6f/GktS+Cz08H9ksh1EjS7dFKT+YGq5jTsxDEJkNB9PUFJj5/Xp5EmB2OmH\n cLGcWiDvzm25xiz77+QWW01LKSrEqDzW+TY39xsu8UW7/U5wu0vZGX4SCoQp40IDseSq\n afE6nq/gN6fL4NPUXHzYyV60mmTJKj89r4KANGBR/ddytWvzSKJLmmsOl6vG+8Hxv/kC\n tK6gEq5gxIcSfZU+QC7ypAnzj1ypxndRtMBmiCD2BbH8EI6G3gk5B32fASiliUAHdrmU\n 6L4VC0nQ/fp62Glt9M2OZiFz0RrD4brGAC54OVlghrs3bdjGMfftmkoWK0Hba4MrKMqy\n gsIA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8cPjuQ3Ko3o+bbL8HjBM0/aU7mczAzUcQJaxrceN8e31yZpKU1PN9/dBqfjnnLVbWtELRtGN3LC6yk@nongnu.org","X-Gm-Message-State":"AOJu0Yw8ZZ5gXz9CYYlnd0Fn/g8mKBJnPAttRzKL92hvPlfVc5kpwHLl\n 220CIT3+EFxBcMSTZV6Rj74N4fBWrcn1hwLuiQcO+a9PJ/2UenebNbH288WgmbR1x6il2JDyE9J\n zhaUuUozSc1bKpVMcC3WzDTaZcUhCviev8eubmY9V5A==","X-Gm-Gg":"AeBDievS+Cof2enSKn3WHIqtsljf9a4YHs9MON1XyKlANjK9R3kNAFYqR/zoX/tGZ1u\n 4n61feEV8HzLaYvI1TjJzGydNmFVDgKYNt1xqKXlJ87cl7gV4jsLC3r6r9MZmgzaCIQN3lj3iq8\n R5iLi8Cx35aw1y4VWE1uP3Nu7ze8Yubap/JQpO47ELXVm9Cv4Q2UR1OX88aohIl4H3Cr7MQgoma\n jqHpLFbRanLnXsONkhiFA7w63/OULCWH463YZYW1pOSbd3Xln2/h2tRkK1WrPXcvrD9J0/8LGA4\n 5zsbVLrbSnOh6ieLOUNGPDDFQZo6jpDx9kiY2LffOBGl67+d+Dnk1MSNauwVu0Tw11oEydyAV1J\n dBw==","X-Received":"by 2002:a53:5a04:0:b0:654:3fdc:7b3d with SMTP id\n 956f58d0204a3-6543fdc80e1mr6513728d50.29.1776960575416; Thu, 23 Apr 2026\n 09:09:35 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>\n \n \n \n <23e33b6a-acca-4e01-aa3e-d702aa45ea4c@gmx.de>","In-Reply-To":"<23e33b6a-acca-4e01-aa3e-d702aa45ea4c@gmx.de>","From":"Peter Maydell ","Date":"Thu, 23 Apr 2026 17:09:23 +0100","X-Gm-Features":"AQROBzCg6gyLXygE-_Oj7GX-VZ_st8gYbTZSbCGbjTfleHV_4Hk-6NRpBNK2p0c","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Helge Deller ","Cc":"Gyorgy Tamasi ,\n Huacai Chen ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Richard Henderson ,\n bibo mao ,\n xianglai li , pierrick.bouvier@posteo.net,\n Pierrick Bouvier ,\n gaosong ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=2607:f8b0:4864:20::1129;\n envelope-from=peter.maydell@linaro.org; helo=mail-yw1-x1129.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3681619,"web_url":"http://patchwork.ozlabs.org/comment/3681619/","msgid":"<81a244cd-2ba6-43ae-8071-90df3c52a1b5@gmx.de>","list_archive_url":null,"date":"2026-04-23T18:32:49","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":1115,"url":"http://patchwork.ozlabs.org/api/people/1115/","name":"Helge Deller","email":"deller@gmx.de"},"content":"On 4/23/26 18:09, Peter Maydell wrote:\n> On Thu, 23 Apr 2026 at 16:36, Helge Deller wrote:\n>>\n>> On 4/16/26 21:14, Gyorgy Tamasi wrote:\n>>> Hi Peter,\n>>>\n>>> Your analysis cleared some things related to this older changeset:\n>>> https://github.com/qemu/qemu/commit/c52e405968341b1d10c618f23bdbb841e39f9255\n>>>\n>>> Before this syscall-NR 79 & 80 (newfstatat & fstat) was not enumerated\n>>> in the old/deleted (non-generated)\n>>> linux-user/loongarch64/syscall_nr.h‎...but these appeared again in the\n>>> newly created linux-user/loongarch64/syscall.tbl‎.\n>>>\n>>> I can recall that I was getting \"Unknown syscall\" messages for 79 &\n>>> 80, when I tried to run qemu-user 8.x.x even with the simplest ABI 1.0\n>>> executable, because even the shared-lib loading phase failed on these\n>>> missing syscalls 79 & 80 (used by the old glibc env of that ABI 1.0\n>>> exe). So in the case of that older qemu-user 8.x.x it was obvious that\n>>> it is not compatible with ABI 1.0.\n>>\n>> I've applied this patch to the linux-user for-next git tree at:\n>> https://gitlab.com/hdeller/qemu/-/commits/linux-user-next?ref_type=heads\n>>\n>> I've added the comments from Peter to the commit message.\n>> Peter suggested to adjust the commit message.\n>> Gyorgy: If you want to resend the patch with a rephrased commit message, I'm happy to take it.\n> \n> That's more conversational than we usually are for commit messages. Here's\n> my suggestion:\n> \n> ===begin===\n> linux-user: Don't define target_stat64 struct for loongarch64\n> \n> The kernel defines 'struct stat64' only if\n> __BITS_PER_LONG != 64 || defined(__ARCH_WANT_STAT64).\n> loongarch64 doesn't set __ARCH_WANT_STAT64, and it isn't 32-bit,\n> so it won't get this struct.\n> \n> QEMU incorrectly does define a target_stat64 struct. However this\n> isn't causing any guest-visible problems, because defining the\n> target_stat64 struct and TARGET_HAS_STRUCT_STAT64 affects these\n> syscalls:\n> TARGET_NR_stat64\n> TARGET_NR_lstat64\n> TARGET_NR_fstat64\n> TARGET_NR_fstatat64\n> TARGET_NR_newfstatat\n> \n> For loongarch64 the only one of those we provide is newfstatat,\n> and that is actually a separate QEMU bug, because the kernel does\n> not provide that syscall for this architecture. No real guest\n> code will be using a syscall that doesn't exist in the ABI.\n> \n> (Some of these syscalls are present in the loongarch64 \"ABI1.0\",\n> but that ABI was never accepted in the upstream kernel, and\n> QEMU does not model that ABI, only the \"ABI2.0\".)\n> \n> Stop defining TARGET_HAS_STRUCT_STAT64 anyway, for consistency\n> with the kernel and to avoid confusion.\n> ===endit===\n\nThanks Peter !\n\nI've changed the commit message accordingly.\nShould I add an Acked-by or Reviewed-by from you?\n\nHelge","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=gmx.de header.i=deller@gmx.de header.a=rsa-sha256\n header.s=s31663417 header.b=OjZTZrQ7;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1l8h5LT1z1yCv\n\tfor ; Fri, 24 Apr 2026 04:33:24 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wFyrV-0003mZ-VZ; Thu, 23 Apr 2026 14:33:17 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1wFyrQ-0003lw-Ex\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 14:33:13 -0400","from mout.gmx.net ([212.227.15.19])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1wFyrN-0001bS-Ol\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 14:33:12 -0400","from client.hidden.invalid by mail.gmx.net (mrgmx004\n [212.227.17.190]) with ESMTPSA (Nemesis) id 1MOA3P-1w0oPq1Kjh-00YblX; Thu, 23\n Apr 2026 20:32:51 +0200"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;\n s=s31663417; t=1776969171; x=1777573971; i=deller@gmx.de;\n bh=5qhqxDte9ARmB4VqgxX6anMdoxTdrP+258rETcJWFHE=;\n h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:\n References:From:In-Reply-To:Content-Type:\n Content-Transfer-Encoding:cc:content-transfer-encoding:\n content-type:date:from:message-id:mime-version:reply-to:subject:\n to;\n b=OjZTZrQ7PBrYp2uUpkFdDFN38WydBGwktJhT7/2T2EQT+Zxq6TCip94FQA6/h0E7\n AxICZjZ+v4zwT1yATLOYdJ4BlV2p51CLZpiIvIV5mcq51WUL5xHQTngSLhlk9dEYn\n x40/LKB8mafuThF/JFSIPctIcCSZi0rrDfnRE3zoiLF/qUgm+6TVdXOmdFwefKFT0\n 6gA3AATLEyeV+otXSzcuIWjEJAYAcxeV0UURiU74q4pI83vEIdf+5FRE3B4prPkrA\n s/5UXwKxnrrVdX8Qthf0F5un0tJ1/QuMT7xTDpg9zUDUFdfH6R9J/UnlBKm7K5Z9g\n pW4pY4GUG86aCV/OLQ==","X-UI-Sender-Class":"724b4f7f-cbec-4199-ad4e-598c01a50d3a","Message-ID":"<81a244cd-2ba6-43ae-8071-90df3c52a1b5@gmx.de>","Date":"Thu, 23 Apr 2026 20:32:49 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Peter Maydell ","Cc":"Gyorgy Tamasi ,\n Huacai Chen ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Richard Henderson ,\n bibo mao , xianglai li ,\n pierrick.bouvier@posteo.net,\n Pierrick Bouvier ,\n gaosong ","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>\n \n \n \n <23e33b6a-acca-4e01-aa3e-d702aa45ea4c@gmx.de>\n ","Content-Language":"en-US","From":"Helge Deller ","Autocrypt":"addr=deller@gmx.de; keydata=\n xsFNBF3Ia3MBEAD3nmWzMgQByYAWnb9cNqspnkb2GLVKzhoH2QD4eRpyDLA/3smlClbeKkWT\n HLnjgkbPFDmcmCz5V0Wv1mKYRClAHPCIBIJgyICqqUZo2qGmKstUx3pFAiztlXBANpRECgwJ\n r+8w6mkccOM9GhoPU0vMaD/UVJcJQzvrxVHO8EHS36aUkjKd6cOpdVbCt3qx8cEhCmaFEO6u\n CL+k5AZQoABbFQEBocZE1/lSYzaHkcHrjn4cQjc3CffXnUVYwlo8EYOtAHgMDC39s9a7S90L\n 69l6G73lYBD/Br5lnDPlG6dKfGFZZpQ1h8/x+Qz366Ojfq9MuuRJg7ZQpe6foiOtqwKym/zV\n dVvSdOOc5sHSpfwu5+BVAAyBd6hw4NddlAQUjHSRs3zJ9OfrEx2d3mIfXZ7+pMhZ7qX0Axlq\n Lq+B5cfLpzkPAgKn11tfXFxP+hcPHIts0bnDz4EEp+HraW+oRCH2m57Y9zhcJTOJaLw4YpTY\n GRUlF076vZ2Hz/xMEvIJddRGId7UXZgH9a32NDf+BUjWEZvFt1wFSW1r7zb7oGCwZMy2LI/G\n aHQv/N0NeFMd28z+deyxd0k1CGefHJuJcOJDVtcE1rGQ43aDhWSpXvXKDj42vFD2We6uIo9D\n 1VNre2+uAxFzqqf026H6cH8hin9Vnx7p3uq3Dka/Y/qmRFnKVQARAQABzRxIZWxnZSBEZWxs\n ZXIgPGRlbGxlckBnbXguZGU+wsGRBBMBCAA7AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA\n FiEERUSCKCzZENvvPSX4Pl89BKeiRgMFAl3J1zsCGQEACgkQPl89BKeiRgNK7xAAg6kJTPje\n uBm9PJTUxXaoaLJFXbYdSPfXhqX/BI9Xi2VzhwC2nSmizdFbeobQBTtRIz5LPhjk95t11q0s\n uP5htzNISPpwxiYZGKrNnXfcPlziI2bUtlz4ke34cLK6MIl1kbS0/kJBxhiXyvyTWk2JmkMi\n REjR84lCMAoJd1OM9XGFOg94BT5aLlEKFcld9qj7B4UFpma8RbRUpUWdo0omAEgrnhaKJwV8\n qt0ULaF/kyP5qbI8iA2PAvIjq73dA4LNKdMFPG7Rw8yITQ1Vi0DlDgDT2RLvKxEQC0o3C6O4\n iQq7qamsThLK0JSDRdLDnq6Phv+Yahd7sDMYuk3gIdoyczRkXzncWAYq7XTWl7nZYBVXG1D8\n gkdclsnHzEKpTQIzn/rGyZshsjL4pxVUIpw/vdfx8oNRLKj7iduf11g2kFP71e9v2PP94ik3\n Xi9oszP+fP770J0B8QM8w745BrcQm41SsILjArK+5mMHrYhM4ZFN7aipK3UXDNs3vjN+t0zi\n qErzlrxXtsX4J6nqjs/mF9frVkpv7OTAzj7pjFHv0Bu8pRm4AyW6Y5/H6jOup6nkJdP/AFDu\n 5ImdlA0jhr3iLk9s9WnjBUHyMYu+HD7qR3yhX6uWxg2oB2FWVMRLXbPEt2hRGq09rVQS7DBy\n dbZgPwou7pD8MTfQhGmDJFKm2jvOwU0EXchrcwEQAOsDQjdtPeaRt8EP2pc8tG+g9eiiX9Sh\n rX87SLSeKF6uHpEJ3VbhafIU6A7hy7RcIJnQz0hEUdXjH774B8YD3JKnAtfAyuIU2/rOGa/v\n UN4BY6U6TVIOv9piVQByBthGQh4YHhePSKtPzK9Pv/6rd8H3IWnJK/dXiUDQllkedrENXrZp\n eLUjhyp94ooo9XqRl44YqlsrSUh+BzW7wqwfmu26UjmAzIZYVCPCq5IjD96QrhLf6naY6En3\n ++tqCAWPkqKvWfRdXPOz4GK08uhcBp3jZHTVkcbo5qahVpv8Y8mzOvSIAxnIjb+cklVxjyY9\n dVlrhfKiK5L+zA2fWUreVBqLs1SjfHm5OGuQ2qqzVcMYJGH/uisJn22VXB1c48yYyGv2HUN5\n lC1JHQUV9734I5cczA2Gfo27nTHy3zANj4hy+s/q1adzvn7hMokU7OehwKrNXafFfwWVK3OG\n 1dSjWtgIv5KJi1XZk5TV6JlPZSqj4D8pUwIx3KSp0cD7xTEZATRfc47Yc+cyKcXG034tNEAc\n xZNTR1kMi9njdxc1wzM9T6pspTtA0vuD3ee94Dg+nDrH1As24uwfFLguiILPzpl0kLaPYYgB\n wumlL2nGcB6RVRRFMiAS5uOTEk+sJ/tRiQwO3K8vmaECaNJRfJC7weH+jww1Dzo0f1TP6rUa\n fTBRABEBAAHCwXYEGAEIACAWIQRFRIIoLNkQ2+89Jfg+Xz0Ep6JGAwUCXchrcwIbDAAKCRA+\n Xz0Ep6JGAxtdEAC54NQMBwjUNqBNCMsh6WrwQwbg9tkJw718QHPw43gKFSxFIYzdBzD/YMPH\n l+2fFiefvmI4uNDjlyCITGSM+T6b8cA7YAKvZhzJyJSS7pRzsIKGjhk7zADL1+PJei9p9idy\n RbmFKo0dAL+ac0t/EZULHGPuIiavWLgwYLVoUEBwz86ZtEtVmDmEsj8ryWw75ZIarNDhV74s\n BdM2ffUJk3+vWe25BPcJiaZkTuFt+xt2CdbvpZv3IPrEkp9GAKof2hHdFCRKMtgxBo8Kao6p\n Ws/Vv68FusAi94ySuZT3fp1xGWWf5+1jX4ylC//w0Rj85QihTpA2MylORUNFvH0MRJx4mlFk\n XN6G+5jIIJhG46LUucQ28+VyEDNcGL3tarnkw8ngEhAbnvMJ2RTx8vGh7PssKaGzAUmNNZiG\n MB4mPKqvDZ02j1wp7vthQcOEg08z1+XHXb8ZZKST7yTVa5P89JymGE8CBGdQaAXnqYK3/yWf\n FwRDcGV6nxanxZGKEkSHHOm8jHwvQWvPP73pvuPBEPtKGLzbgd7OOcGZWtq2hNC6cRtsRdDx\n 4TAGMCz4j238m+2mdbdhRh3iBnWT5yPFfnv/2IjFAk+sdix1Mrr+LIDF++kiekeq0yUpDdc4\n ExBy2xf6dd+tuFFBp3/VDN4U0UfG4QJ2fg19zE5Z8dS4jGIbLg==","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"quoted-printable","X-Provags-ID":"V03:K1:74kTKRZo+xebsIom+pJ6X2HsFCNhgI/7OEjO1r9H2RN6rV0RfWZ\n ocUkRAPQGGzcsz5lfhVMoNRab0BoBdzjZyxwC2KANsItrRvlXUvvXLnQj0H7ONZ9RQBokFs\n Dv381wEkLDKZWJ1mTcu6dMEEOEcP8IidBYEXRxLbmP37Xs/WEwjhH56eFD5GsZHIxjCNZiu\n BM/uQhWmAtlehnZYdxvsA==","UI-OutboundReport":"notjunk:1;M01:P0:ZbtNIvL+eds=;zBcXTHWTAgMDu/EIHm0ZJUhHz8z\n uuc80j/MHO3/WPyTdWkcreyHV20yLQiiZr1GkDZez1/KoyMl6/DLXG3c1Pf3RyAoR0OiZod2G\n 7VZz2BUOr+KE9DfrtSDoOG8X37fHPnH8Q5QMtJ9uQ9P9NBFbhAtw5uUQRI+goD23WlBPurC4C\n SBvtSACSe5iHIKYqd/4s0dcLpHkpw+hgupm9YETe8nNNjNa17vbnUYDWyT3W9DYDGF056o2xT\n ZL4L8m8lzd8EOWnWpp8MNBEW9xe/j01N+ddpPbV80CI5m+dzLZAk0MJkj+/5ky4WgmH/P5UrH\n hW1HyUGcgMS4RlXRyzINcV/vE33vxw/p5ixLjPKPREq2GgntOXwa1hJKU4G9gqHZuPaLhB9lX\n lyOm4AVW5GX6dadjA3fJBOKVspGrF2VmxAeRfNVhCCGZdhhX5FWXeivlMmIzDApaBQfvvtOh0\n FY2USVQ0nKP4WYiKllU98yUCgw4PgaMOKW5Po7QV+sINm8h2bV4e5WFMJ9GieiGtS4hNQzPa3\n t720Autgvag1j50jnj8mQ0pOJqrKVb1IE7Rbg5th0oxQQT4yrBmvRLicMCiggKB1RhWO2/zFp\n aySEaTRmaeMB5Qe0gQLQjDue9KgJ9knknGXbb5YdXvIUd/M8YGE9muWPqUCbs/F7oXDFweaaZ\n OR8FHMnghLirLZOFopHZpppIy8GoHjnHuzerqxtRgIykSvCW9jN4SLn2VxoFwV+iAyKTdjs0C\n UiR9ayhrIvJ/YXOLHqoVbRJbhfAqRrlI/umCKZw7qVH9cezLgox7jo2ELvdhkQ0HCj86ZLnQg\n XKLKXA/L0n58fCpY2pUq52XJnRZyStPBjaNHHVVVU+JqaiktwY/RaLDCFkxFu6A50DMj73Pja\n fPkK2V/uzwYhqyO8jQbp42p+KPAMMO1DOSNF01jHkVvYZcGzSYImdlOyWUYuBZ2uTAGFBtVGB\n CYWhRoG6miOF8aoFdl7apj+UtKXTkucWWgycLJT2sPgdy8O2DU3x6L3p/yoQwNuL9dMqIqKry\n eqrOBq2bo/SFRPrwRhWO4J9UnMS4mFG+Qbmg5Gc1Oy1yQQt7VHHoz2RiNLAp2M7QzN0z31dRd\n 4Nl/ejV0/zF/HlpH1aC17bPGYsv6D80Ius+ijZFU3k5JcrQKMkqboF5xVErbWocfObXNNEIiW\n AJsKItOEY+uPACQLf8PpdSUoMv/TUbvc08eekCiK5T7q6BpsEgd8YFcKi7O6Fk+fu8Xvg3Cdg\n TW7imEyW8eMnRgLBpDP2un/PdckRQuj+ViauiMphlGVcjhzvJWWKLZ1yNiVjew1gwHFvXA0T9\n wfoGKN6wnS9euUmvnsgpB82NLtabVbABIbimF/C0LYhdP22gzhTe4VY08ps8+QGP2fHKqNDFt\n ySOxlYNZ+X6UyKIcGpebv8DAv5d9HMtYFfEusGLkyh6XESuvh1K/Qn6tw14dvFCwR6XK5d5QO\n XCgVMJUd1Rx8/Gb3KqzMnaPEMBWyvtkXSx2RICEa9bif6wFGgMN2OY+vvfMFzgJaaq1ZvXSwp\n fEwlqg34FHXlRHMfO1+RzCIsKzh1BxGfR8tnJYEUPi7IIH5IMbI6lU9QvVJRoEtHliAyThHbK\n PYiXSvNQ8A6NvCQSOzFs1DT/WEeB4WUHbVd/SZ7f71W2xF/yfkyfZglFOFn8xvkjIYaswk6ee\n yHybUXVNs7+vU+p057MuNoVu9ktpyrzprC15tcFLcrCO5+wW73RzVXDWzOoGED1X+gRNtlmxk\n G4r6UgfadcH/a8Vn7E6xFSvknJ+pkhft4TRPN4+A7EtOe/HyfWupMtpeq0whZKvEW+5VEtWnp\n Eq6nfYR/FDYASlPsqN4LT1qxv+WVMK61dpz3Yun29PY4xMkAhY77AOJrBCMZD+Tuuzwf74f2l\n Q+sruIpSHIzrw+9kaZL2jUjG1Mvxyx5V427Qkj5fOHpOaUUNo12btbv++VS6R3tdx7b0O7Ds3\n XOrjFb9TQXIX/2gm4mIVTEt9wfUHVVvDXAr1z/b0bMaGaAbw8Oz2UEtcDbfH4+aK4H/b63Gcj\n yTUPM3UA6a5lVcNwP6FBwL/OGQzgoYo1gzhq6lSqKeAGeI1YzBO32ZLxNDUOerA20tC6W5Wk6\n /X0oEucKOGV2Noo9hwZQnz6LZwLbv4/xUY6qcbwZcXdc7tSY2P1qETqW37nhCoNoeXqOYVCoY\n kH0a1moCZjEt/3y4eGesPzxxWxR6swQXiWQXuqVp0j1+zkmKitJU/i0dLBw3E3lDFwaqKLTFx\n No7pC5oQ5ALjokZvtltWu53GHbVa8dnQdRQTPJB5LT61/i/BxPJ/GVb6+K3fKV+KjpO6tg/FQ\n OkpaUvEHjlNYXKRCFoUfN2ftWTzwlhlxLSGQJwGeuPs/DeQxw87SJ2m9x8HP/j2HXu0Nvqn/V\n BdOTAcedA+DCMUiNdH/Jsx3tfiI2n4G1y/PvlYg2EG1qdaJzzyfhG1MRtJrnGHLUUq6s2AJHY\n t1YJVfcP19RWwfex5xTxw5zZakl5iqcW9hoERlovKdZUu04R7J6XvT8m51uUb1B8pa+Rf0Mh5\n ACMgQ/tKdSVst+I8xU9RtONHm9HK7CCVh7l+mUffChvBxKDak4GY+WlFZoA8DHZXdvmEGqlMr\n NbLI4GW2+cokhqkaurjaA81Car7n6Z6eBon5lbJs2JctW5fZTb8sMDYg9BNbbEI6ig2XTg+Oz\n oUe1mFFT/zpJmekgoJrxOqIlyX1SevKXLbzPDHP+BC1ClXmdMUCQON32OVrQbmEzL7ckwPb8c\n jp0NrjCTeM7dhK5cvitt4/8UKNntYrfWxaStAtxbTACxu/20Fne6X+2MhrvJ8vWvrCGv+sLmN\n VKdufH2S06X6639hEVYBDJJ92E5kqq0uQtANSop4rDHz83uXqBaoJ41K1wq5VquC430k1scCO\n TL+ddYYh7ljFyubQivALE0+gtkTerDvGNlUuEX5W3jdb8Z4VSKGmbKLStt1V1ChqJx8sBwX+Z\n fsHDTa2JPAlZST0l+jetSuXyuFR+erltWCST3bmBo1ClGcTJn/+YRMJr1wbw9wL9hWGXZL/Dp\n Nwwa0qViNuyIzWiP87aUgCQxD9jIXPzeVwZecN7gc5kVvkE7qtNHISfCNhNeW+LUJnZLTcho/\n H5sImtGoM3zpY+PloOSVqjvP3KtXXrK7maQ/PIETc7svH78wPuiZgP0NCqsb31LE7W5rSpflS\n 8tQgfboXr6KxfRREDj8UK0XmAWPiMFtlIswhpVHMt0Dfp3BICbWB/UFV0olZcbebu80d0sMyZ\n NFZNt+u7RBkCugWo/eFjOsgbr1xmZZ9HiIZINW1WBwCqA8YI05jQ8YxGCE8INqhVJXzxL5Hj1\n goTqcYvyLfdnJk0u7vkqa18YdGLL/r147b50N8ZMEmHnkufZU0FEEUQ9GGH5yp205dCdW8VEr\n YNhrXtVhkG6iMQ5R6lwMgf3kJ1ARoA11w8rR4Jid8353i3lBakmtOMN3DeV8UD+enWESYvKOn\n zXR4phtgsXaQYwmTLZJ0p15KBfw0umrNpMP4RHFpCtnebuddhZlwBQAHP9+UFJJIy2HU3Wp+z\n 6kaoodFxif3VldHErgjr6qjsoB6Mt1Cz5gV5wSnmgitzj6bVc9C+06HS3+R9UE43xg7vid+VU\n oVSoJ23cLTUTJE1L2/ONHlJVQ6l1ydpofofrK9Nxu30MWxG5BqCKdLVek4GBCvlXrWyQWFMgR\n bcOZm6ffdtiuj9ZwcupXhLAZbjpfXpwS+76J27ZXMqGry0KCR3uDQNlBA78+uOCkZCxuMKNIy\n fa3NEALjPMNqiL0sicQ9481aG0nfOyRgARlqP9tar/VAOmI1WQIQy/RO79MOD+Kz/OdOZTOzD\n jL74S/RZgLOy5CNT6KC3bHystCKRU7XLEGJSYNYYJ2GyiUlA9NLMT4FuoT4lp5r1zgrr0L5JP\n UYhvjTewHcgZPCx9au//0KosR1dRLTVwxHgRceqqvrjOLS5YnixmbFerJ6AhymS2TBL4QycjK\n 6XjVzKV3YZh+ffxuPEdgSuNGixLEJ2pOdsIl+y5fmRAZ8IvteNZL1/BTiLoV5kGBkFrM4lUYy\n 94d65cyNgUixlgFwW4di91TZNVxzwHqehbvIRXUiPq/8WBh3By41e7RSRlgcxbmitoaPEkJ3N\n D+4D055PNf5K2Oyin2VXdQkwsvq8oaBMCms67KyDj4CyUy5aUBFfw/XRFmPWNSr6w/KwgXSAm\n MTtZXFYKVNdZtDu1RyJ1aGfEJx8LpLyHMYe8e65TRUHLovy6JF6HPQMHqSjIte0ltpmfCEzTm\n K3z90Xqd6poxdT5357R6xSN8D/Hqor7F3Yot4msUnDo71A2xNJYAk5PigRiet0968+RjI2UIj\n fpmLCmGftHaq90PSfOUUU/85xB7fGAh6JHxhL7XQ0mcXNmEhrP//X9Ft/1p8R3wxSuuvzJF/F\n bTOYo2mzIitcYe7OmwRuj6bix7IF7PfqEkpqO5ai/N6bHxjp7e9xtO65xPnJLYMqOzWZqQdrF\n AykcxGA6GLLi+REzdL0xz8c38QM4paEfD1wtgSm128UPwWCMb5xO6v4mzZp1n8w5YxJWnhatc\n CgTbMGRzYizIBSjbXSsO6lgz6Rgqi2O55hO2s5A0o2CGgZacnRwcRQe/gzOZdarUowLV71aMi\n XEBTYabhaMWpfPbUxWoBZ+LtUsGTThxKxE2n5G8PGYZ9IpfKeyZ0F7U0+Fhaw0z630+Vnhm+g\n UGx2dlS5nuMpsq3QnQPFOoXtKyJJTDlmATzruR/LH8p1UF3Zk4LJLmmgyLCwyuTrBcSxse3LY\n 4tOfsX/cEj0q5qtBXu5J9r8lfeiG35i2njSaM9nlXF8W4AbYlgq7nL3knNNqnT1x95BamSPCK\n v7JUrmRYgE27OjaSF5exm0AAW9Vf9JyZAzDcrCAmO3x0RBEi9S7FVuqyh5nP0XUhS1S5LI+OZ\n nnlkJearGjVm5l+kJ2FcVFtvLW3qQ55LYkiGRKUQOrKaX8UpIEBlndnakZGugR/vQ7t7+hvsw\n WzdWXPP/LcPQN5PILzb+ffn9yD3E2aJNOYz+UrwLT3WjD7Y8DKpAXZIqwPtVYVsj1T6IM8V0y\n Ycatr/gT+dCP0/yfdmFvV/01jgE3HbWCB1JVHeT0ZY4R4g42oIZTDtdUx7xHwYWcYaUmJXXZE\n U63YFwGqMzLtu8KFl9uwz6YMvH5pxysAoreDSlyb6Q6Z0Tb5XeKE/k8rf8dBYIZXeWVnr14Hu\n UVnWXiieRpEZmbntOdiA1G7BNj75wBTvqATcyszRHMAdPoNwwQ7Al+IWvHYZmX18UHgoFQX6t\n zjz36O5OUMpzO3VBmj1CVGkuUA/epCl7ysi3ry5C4SiYjKRw8UJMmMMIS4qQEJzRxoiqqg42F\n UvzxfV6VtX3X2uhuot3+rFpQaPBcPtJqQRCgs12531l+9MJWuv7gOhgEzZIRY4EMLwCDWvLLp\n ryiZ82m642l/3QSI4SsoRZgKfYtp37QIXFDc0DqQ+U9Qdnm8SVdPY2RXozn6MOMZQ57M7pKez\n e2XGIVRL0P5P2TNFBmZvWokwLylBueWYcsLBuMmPPFmqqDzC9ERcdW9fuWoKlKG6vHW0QILFJ\n /KKt1A==","Received-SPF":"pass client-ip=212.227.15.19; envelope-from=deller@gmx.de;\n helo=mout.gmx.net","X-Spam_score_int":"-27","X-Spam_score":"-2.8","X-Spam_bar":"--","X-Spam_report":"(-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3681632,"web_url":"http://patchwork.ozlabs.org/comment/3681632/","msgid":"","list_archive_url":null,"date":"2026-04-23T19:01:43","subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","submitter":{"id":5111,"url":"http://patchwork.ozlabs.org/api/people/5111/","name":"Peter Maydell","email":"peter.maydell@linaro.org"},"content":"On Thu, 23 Apr 2026 at 19:33, Helge Deller wrote:\n> Thanks Peter !\n>\n> I've changed the commit message accordingly.\n> Should I add an Acked-by or Reviewed-by from you?\n\nYes, you can add my R-by tag.\n\n-- PMM","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=P7dYTZEa;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1lp17072z1yCv\n\tfor ; Fri, 24 Apr 2026 05:02:17 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wFzJG-0004am-NJ; Thu, 23 Apr 2026 15:01:58 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wFzJG-0004aZ-6I\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 15:01:58 -0400","from mail-yw1-x1129.google.com ([2607:f8b0:4864:20::1129])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wFzJE-00038w-NA\n for qemu-devel@nongnu.org; Thu, 23 Apr 2026 15:01:57 -0400","by mail-yw1-x1129.google.com with SMTP id\n 00721157ae682-79db5e18ac6so85055557b3.1\n for ; Thu, 23 Apr 2026 12:01:56 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776970915; cv=none;\n d=google.com; s=arc-20240605;\n b=j9WDkMPGkRloKyG1QctHYro0abvqhtJsh9bugNmYeNewd8lotV3uz85RKXcPZcHT2b\n zZJfOhcqL1Ll6mPhwiO4YLfR9Wsrc14k5TFRwX3g0xkfTaLI4VUJXGpYaqMip2PzTK5d\n MDT3dRHpmQ+o/7DWTDFgBxsJ2fUcKYkWn/fW1mqA5MOg2rs3ZjL8h9IDC3puVRF0oVyM\n iKWOuro6I6xhDNf30lkC30nfDMjC+wrF7AmlTGb74ZEIJz8cLnw0rhyFwMPZY2/cyx1s\n ZkvonBkoDQYSMBuak/Jdb5XCBr9U/T0MNf1XHmN/m69YXPI7THxyF2KBiHurXTvODBoA\n q2EA==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=B5zwKjAIc8+MGHRRSySYoKSERnHY92hjxdFN/pjgdK0=;\n fh=bJmps0/GYrffiBUvJ9cR3IgPCmpf4tiD4yrJ764HH8M=;\n b=UuhK7mvjDtQHl4NRQsCJIQLhTnP+OdkfIpEEu2iTzpOP78eLJt1rtEERNqsCZOFdO6\n AOPTZUBWBWt8CyN9JRczR3ATG+n0xtcEbGUtSjPjTCA+vZv+n+oES3lJsVh4/qWfNze8\n dXtiRYamzzvsdlVH4SMVnDgRxnC6/k67KM7O4l+6q8vPs7T7BFVlWnpYYXC8XUfsm2Fy\n 64P7vv2OiXRCSAJtXgUZKhL2MEDeDzafWADwAwd/PZwLoRhvaPBqwc2yGeuY0Wiqqw54\n sht/fnhRwpt9/u+8AwedQuw+gyQI9RAUUEE9w+63ayb8WPcFFpptOymPSQhwmKQj98lI\n 34rw==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776970915; x=1777575715; darn=nongnu.org;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=B5zwKjAIc8+MGHRRSySYoKSERnHY92hjxdFN/pjgdK0=;\n b=P7dYTZEanCyBFqM7U60E5KRMnvy5/BnUQbvWYZnYF4curv4CND/pTFLSCpTOaVoeUj\n NIVMk2FZGR36HRmJ7mywc6NORKF+fwxLeN+rfpdTyn8nKZlE9d75J8lY5G/sNKNCmSST\n iHgoPozURNOGijhOMIuHjodeFt4a5SOeJbF6gsV7raJ5hQRbPf3kUNVwTPkSf91B7cwx\n ZjesAp7pDk5dDFN9ri/YhYeLx406Fxei/Vf/4rWUgiSdjByLP1+KBZtTRhPbr+bU6RD8\n MhciJkb4HVQAqUTtf0LRp/7oAnhC27bu4W2Tf/QwzsZIQsx3c43ARsX5TlA3xmPlL13Y\n vwRg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776970915; x=1777575715;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=B5zwKjAIc8+MGHRRSySYoKSERnHY92hjxdFN/pjgdK0=;\n b=DyOFci491P36qrGiaw5h2d0PS5W4Fw04CUQROlZWHh1etK9nCIYba6tMZdG/PF2GDl\n 30FWl54VUxrHFcx8SS74V5xVlZSrRmk4DA7+50KDnkSTHRHiRDYQN16xOi6ql742JPwL\n K5Q92VowFNemMOD5Uo37LBHRsCxgwX9U2qU7ZP5k/lK5kplvjKymW5ybGDYt2vK8F1Tt\n CpxJDQasAW3hKBDjjzWRVesDOlURHs/wFqBJaS94y9NMlbCBPiJK9KjuiqtbM+QCV3v0\n 441mgusaEw4Hz87uFlopBl7txJVfZUzEU3F3PEeShRkjWhYzZV0zv4c9ZKDLICc9gIfW\n 9nOQ==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/h2IdfSmyW0FlXWnAikYp5OnZ+8u6Qd7pBFnj/aYmOEiLWX2pR/Yw9/HIkEK2x2Zmd7fuuFBmSdO6V@nongnu.org","X-Gm-Message-State":"AOJu0YyLIj89uzkqUfgJWvQJ7d5lDuLFhiI/ViOIFAbURPFlbBOufw9g\n dAWnQLU4QHnjDmuIrWEzAcdQ5W2iBAxwYGEdTzTdg1C8y8Zgwrh5Vq7iCwG5iNO6EVZYgu5vDcT\n DT6k7YicOoPNdwVZchO2JFQbA88U0ekGfJ563GN5ksg==","X-Gm-Gg":"AeBDiesOjopruiVmprZoTbYCp3Pfl5LPabZezOU+ZB1c2vKciui7i/yQrSYGdFprlT7\n 5gAGXUEPrFvfvVwEDUtkDfuGPa/ZKPWOGNTRJaCbw0ZyR8Lz7ijKSdo/6O+NLnM7Tm4w0nFVjz5\n T2x+VPcTlQRARkA2R69S5UUK3fl6QrPrit172wz9uFEUXOUIIPk12yhWARvXGoB7Uu2dGZJtl9P\n F5Jlk/L6TnGIKoMoOdlP6sAqzjgw821uQsL3gj3p1BeWMhfGerShRi2EoDviPj698YbsiiVK16i\n L/Y1QVhsx2ezncXUVYzkHxmiPIexpZuqrnat/HjjPUPaQGG+jprXV5PIhWfuBbjZ97hNFDNN5xY\n +cA==","X-Received":"by 2002:a05:690e:4842:b0:654:6a61:fb60 with SMTP id\n 956f58d0204a3-6546a620b17mr1618358d50.26.1776970915483; Thu, 23 Apr 2026\n 12:01:55 -0700 (PDT)","MIME-Version":"1.0","References":"\n \n \n \n \n \n \n \n <73b6b6c0-81ee-b054-ad59-3067a718b492@loongson.cn>\n \n \n \n <23e33b6a-acca-4e01-aa3e-d702aa45ea4c@gmx.de>\n \n <81a244cd-2ba6-43ae-8071-90df3c52a1b5@gmx.de>","In-Reply-To":"<81a244cd-2ba6-43ae-8071-90df3c52a1b5@gmx.de>","From":"Peter Maydell ","Date":"Thu, 23 Apr 2026 20:01:43 +0100","X-Gm-Features":"AQROBzC3TRcvGFgFbQ7v2JSc4NSIigihMYMo-G7Hp5xE9YScB3lgzz9XDQiVRIs","Message-ID":"\n ","Subject":"Re: [PATCH] linux-user: fix usage of struct target_stat64 for\n TARGET_LOONGARCH64 in syscall_defs.h","To":"Helge Deller ","Cc":"Gyorgy Tamasi ,\n Huacai Chen ,\n Pierrick Bouvier , laurent@vivier.eu,\n qemu-devel@nongnu.org, Richard Henderson ,\n bibo mao ,\n xianglai li , pierrick.bouvier@posteo.net,\n Pierrick Bouvier ,\n gaosong ","Content-Type":"text/plain; charset=\"UTF-8\"","Received-SPF":"pass client-ip=2607:f8b0:4864:20::1129;\n envelope-from=peter.maydell@linaro.org; helo=mail-yw1-x1129.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]