linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

[PATCH] linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

Posted by Gyorgy Tamasi 2 days, 22 hours ago

In a 64bit LoongArch64 env (both TARGET_LOONGARCH and
TARGET_LOONGARCH64 are defined!) we can not use the struct
target_stat64 for data-transfer, since this struct target_stat64 is
defined for 32bit environments with its int-sized (4byte) st_*time
sec/nsec components.
The user side compiler headers of the LoongArch64 env uses long-sized
(8byte) st_*time sec/nsec components.

(This is similar to the case of 32bit vs. 64bit RISCV: the original
code does not use struct target_stat64 in 64bit RISCV env, when both
TARGET_RISCV and TARGET_RISCV64 are defined.)

This fix is important for LoongArch64 ABI1.0, where stat() is using an
fstatat syscall with this struct target_stat64, if its usage is
enabled.
(In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this
problematic struct target_stat64 is not used, struct statx is correct
in the LoongArch64 env.)
See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371

Signed-off-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
---
 linux-user/syscall_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 679af640c0..6967306be4 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2005,7 +2005,7 @@ struct target_stat {
     abi_uint __unused5;
 };

-#if !defined(TARGET_RISCV64)
+#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)
 #define TARGET_HAS_STRUCT_STAT64
 struct target_stat64 {
     abi_ullong st_dev;
--
2.43.0

Re: [PATCH] linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

Posted by Pierrick Bouvier 2 days, 22 hours ago

On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:
> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and
> TARGET_LOONGARCH64 are defined!) we can not use the struct
> target_stat64 for data-transfer, since this struct target_stat64 is
> defined for 32bit environments with its int-sized (4byte) st_*time
> sec/nsec components.
> The user side compiler headers of the LoongArch64 env uses long-sized
> (8byte) st_*time sec/nsec components.
> 
> (This is similar to the case of 32bit vs. 64bit RISCV: the original
> code does not use struct target_stat64 in 64bit RISCV env, when both
> TARGET_RISCV and TARGET_RISCV64 are defined.)
> 
> This fix is important for LoongArch64 ABI1.0, where stat() is using an
> fstatat syscall with this struct target_stat64, if its usage is
> enabled.
> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this
> problematic struct target_stat64 is not used, struct statx is correct
> in the LoongArch64 env.)
> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371
> 
> Signed-off-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> ---
>   linux-user/syscall_defs.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

Re: [PATCH] linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

Posted by Gyorgy Tamasi 2 days, 4 hours ago

Tested-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>

Additional independent testing (bug + fix cases) is documented here -
see comments by sourav/@kishu279:
https://gitlab.com/qemu-project/qemu/-/work_items/3371

On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
>
> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:
> > In a 64bit LoongArch64 env (both TARGET_LOONGARCH and
> > TARGET_LOONGARCH64 are defined!) we can not use the struct
> > target_stat64 for data-transfer, since this struct target_stat64 is
> > defined for 32bit environments with its int-sized (4byte) st_*time
> > sec/nsec components.
> > The user side compiler headers of the LoongArch64 env uses long-sized
> > (8byte) st_*time sec/nsec components.
> >
> > (This is similar to the case of 32bit vs. 64bit RISCV: the original
> > code does not use struct target_stat64 in 64bit RISCV env, when both
> > TARGET_RISCV and TARGET_RISCV64 are defined.)
> >
> > This fix is important for LoongArch64 ABI1.0, where stat() is using an
> > fstatat syscall with this struct target_stat64, if its usage is
> > enabled.
> > (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this
> > problematic struct target_stat64 is not used, struct statx is correct
> > in the LoongArch64 env.)
> > See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371
> >
> > Signed-off-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> > ---
> >   linux-user/syscall_defs.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

Re: [PATCH] linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

Posted by gaosong 1 day, 7 hours ago

在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:
> Tested-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
>
> Additional independent testing (bug + fix cases) is documented here -
> see comments by sourav/@kishu279:
> https://gitlab.com/qemu-project/qemu/-/work_items/3371

Hi.
Please note that QEMU is not compatible with ABI 1.0.

If you absolutely must use ABI 1.0, the branch below is the version we use.
https://github.com/loongson/qemu/commits/9.2-tcg-old/
  
However, this branch is quite far from the mainline.
The QEMU mainline follows the kernel mainline, and
I believe this is the case for other architectures as well.

Thanks.
Song Gao
> On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:
>>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and
>>> TARGET_LOONGARCH64 are defined!) we can not use the struct
>>> target_stat64 for data-transfer, since this struct target_stat64 is
>>> defined for 32bit environments with its int-sized (4byte) st_*time
>>> sec/nsec components.
>>> The user side compiler headers of the LoongArch64 env uses long-sized
>>> (8byte) st_*time sec/nsec components.
>>>
>>> (This is similar to the case of 32bit vs. 64bit RISCV: the original
>>> code does not use struct target_stat64 in 64bit RISCV env, when both
>>> TARGET_RISCV and TARGET_RISCV64 are defined.)
>>>
>>> This fix is important for LoongArch64 ABI1.0, where stat() is using an
>>> fstatat syscall with this struct target_stat64, if its usage is
>>> enabled.
>>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this
>>> problematic struct target_stat64 is not used, struct statx is correct
>>> in the LoongArch64 env.)
>>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371
>>>
>>> Signed-off-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
>>> ---
>>>    linux-user/syscall_defs.h | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

Re: [PATCH] linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

Posted by Gyorgy Tamasi 15 hours ago

Hi,

Thanks for the link of this separate Loongson-maintained 9.2-tcg-old
branch - intended for use specifically with ABI 1.0 code.

This separate branch still contains the same bug (in the context of
the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where
fstatat syscall can be used by glibc, and it can trigger the usage of
the related erroneous data-conversion workflow based on  struct
target_stat64 with 4byte sec/nsec fields):

This changeset was the last mod of syscall_defs.h - but it still
incorrectly modifies the condition of struct target_stat64 usage:
(~ "Add Loongarch64 old ABI support")
https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99
(line 2006)
-----
-#if !defined(TARGET_RISCV64)
+#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
-----

This is the broader context in this 9.2-tcg-old original version:
Here the 2nd embedded "|| defined(TARGET_LOONGARCH64)" normally a
no-op: always true/false if the 1st "|| defined(TARGET_LOONGARCH64)"
is true/false.
-----
#elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \
        || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \
        defined(TARGET_LOONGARCH64)
/* These are the asm-generic versions of the stat and stat64 structures */

#define TARGET_STAT_HAVE_NSEC
struct target_stat {
...
};

#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
#define TARGET_HAS_STRUCT_STAT64
struct target_stat64 {
...
};
#endif

#elif defined(TARGET_HPPA)
-----

The correct fix is the same here (~ disable the use of this struct
target_stat64 - instead of explicitly enabling it for
TARGET_LOONGARCH64 with the "|| defined(...)" part):
-----
~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h
--- syscall_defs.h.ori  2026-04-10 20:53:34.639034304 +0200
+++ syscall_defs.h      2026-04-10 20:55:12.219347804 +0200
@@ -2003,7 +2003,7 @@
     abi_uint __unused5;
 };

-#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
+#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)
 #define TARGET_HAS_STRUCT_STAT64
 struct target_stat64 {
     abi_ullong st_dev;
-----

The same test-scenario of
https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used
[with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old
toolset] to show exactly the same bad & good test results - without &
with this mod.

Just a personal experience based side-note on ABI1.0 compatibility
with mainline qemu (~10.2.2):
I'm working on porting a quite large code-base (a commercial OCR &
document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and
I'm trying to check correctness of my actual builds using the
regression-test package of this codebase. It runs quite complex
workflows of general CLI code. I accept that this is not a
comprehensive test with all of the edge cases or touching every
special areas (like signal handling) of compatibility of ABI1.0 and
mainline qemu, but...the ABI1.0 version of this test-code seems to be
able to run with mainline qemu-user 10.2.2.

Best regards,
-tgy

On Fri, Apr 10, 2026 at 11:37 AM gaosong <gaosong@loongson.cn> wrote:
>
> 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:
> > Tested-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> >
> > Additional independent testing (bug + fix cases) is documented here -
> > see comments by sourav/@kishu279:
> > https://gitlab.com/qemu-project/qemu/-/work_items/3371
>
> Hi.
> Please note that QEMU is not compatible with ABI 1.0.
>
> If you absolutely must use ABI 1.0, the branch below is the version we use.
> https://github.com/loongson/qemu/commits/9.2-tcg-old/
>
> However, this branch is quite far from the mainline.
> The QEMU mainline follows the kernel mainline, and
> I believe this is the case for other architectures as well.
>
> Thanks.
> Song Gao
> > On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier
> > <pierrick.bouvier@linaro.org> wrote:
> >> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:
> >>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and
> >>> TARGET_LOONGARCH64 are defined!) we can not use the struct
> >>> target_stat64 for data-transfer, since this struct target_stat64 is
> >>> defined for 32bit environments with its int-sized (4byte) st_*time
> >>> sec/nsec components.
> >>> The user side compiler headers of the LoongArch64 env uses long-sized
> >>> (8byte) st_*time sec/nsec components.
> >>>
> >>> (This is similar to the case of 32bit vs. 64bit RISCV: the original
> >>> code does not use struct target_stat64 in 64bit RISCV env, when both
> >>> TARGET_RISCV and TARGET_RISCV64 are defined.)
> >>>
> >>> This fix is important for LoongArch64 ABI1.0, where stat() is using an
> >>> fstatat syscall with this struct target_stat64, if its usage is
> >>> enabled.
> >>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this
> >>> problematic struct target_stat64 is not used, struct statx is correct
> >>> in the LoongArch64 env.)
> >>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371
> >>>
> >>> Signed-off-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> >>> ---
> >>>    linux-user/syscall_defs.h | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>

Re: [PATCH] linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

Posted by Huacai Chen 8 hours ago

On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi <gyorgy.tamasi@gmail.com> wrote:
>
> Hi,
>
> Thanks for the link of this separate Loongson-maintained 9.2-tcg-old
> branch - intended for use specifically with ABI 1.0 code.
>
> This separate branch still contains the same bug (in the context of
> the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where
> fstatat syscall can be used by glibc, and it can trigger the usage of
> the related erroneous data-conversion workflow based on  struct
> target_stat64 with 4byte sec/nsec fields):
>
> This changeset was the last mod of syscall_defs.h - but it still
> incorrectly modifies the condition of struct target_stat64 usage:
> (~ "Add Loongarch64 old ABI support")
> https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99
> (line 2006)
> -----
> -#if !defined(TARGET_RISCV64)
> +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
I think this patch has nothing to do with ABI 1.0/2.0, it really fixed
a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.

Huacai

> -----
>
> This is the broader context in this 9.2-tcg-old original version:
> Here the 2nd embedded "|| defined(TARGET_LOONGARCH64)" normally a
> no-op: always true/false if the 1st "|| defined(TARGET_LOONGARCH64)"
> is true/false.
> -----
> #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \
>         || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \
>         defined(TARGET_LOONGARCH64)
> /* These are the asm-generic versions of the stat and stat64 structures */
>
> #define TARGET_STAT_HAVE_NSEC
> struct target_stat {
> ...
> };
>
> #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
> #define TARGET_HAS_STRUCT_STAT64
> struct target_stat64 {
> ...
> };
> #endif
>
> #elif defined(TARGET_HPPA)
> -----
>
> The correct fix is the same here (~ disable the use of this struct
> target_stat64 - instead of explicitly enabling it for
> TARGET_LOONGARCH64 with the "|| defined(...)" part):
> -----
> ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h
> --- syscall_defs.h.ori  2026-04-10 20:53:34.639034304 +0200
> +++ syscall_defs.h      2026-04-10 20:55:12.219347804 +0200
> @@ -2003,7 +2003,7 @@
>      abi_uint __unused5;
>  };
>
> -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
> +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)
>  #define TARGET_HAS_STRUCT_STAT64
>  struct target_stat64 {
>      abi_ullong st_dev;
> -----
>
> The same test-scenario of
> https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used
> [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old
> toolset] to show exactly the same bad & good test results - without &
> with this mod.
>
> Just a personal experience based side-note on ABI1.0 compatibility
> with mainline qemu (~10.2.2):
> I'm working on porting a quite large code-base (a commercial OCR &
> document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and
> I'm trying to check correctness of my actual builds using the
> regression-test package of this codebase. It runs quite complex
> workflows of general CLI code. I accept that this is not a
> comprehensive test with all of the edge cases or touching every
> special areas (like signal handling) of compatibility of ABI1.0 and
> mainline qemu, but...the ABI1.0 version of this test-code seems to be
> able to run with mainline qemu-user 10.2.2.
>
> Best regards,
> -tgy
>
> On Fri, Apr 10, 2026 at 11:37 AM gaosong <gaosong@loongson.cn> wrote:
> >
> > 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:
> > > Tested-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> > >
> > > Additional independent testing (bug + fix cases) is documented here -
> > > see comments by sourav/@kishu279:
> > > https://gitlab.com/qemu-project/qemu/-/work_items/3371
> >
> > Hi.
> > Please note that QEMU is not compatible with ABI 1.0.
> >
> > If you absolutely must use ABI 1.0, the branch below is the version we use.
> > https://github.com/loongson/qemu/commits/9.2-tcg-old/
> >
> > However, this branch is quite far from the mainline.
> > The QEMU mainline follows the kernel mainline, and
> > I believe this is the case for other architectures as well.
> >
> > Thanks.
> > Song Gao
> > > On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier
> > > <pierrick.bouvier@linaro.org> wrote:
> > >> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:
> > >>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and
> > >>> TARGET_LOONGARCH64 are defined!) we can not use the struct
> > >>> target_stat64 for data-transfer, since this struct target_stat64 is
> > >>> defined for 32bit environments with its int-sized (4byte) st_*time
> > >>> sec/nsec components.
> > >>> The user side compiler headers of the LoongArch64 env uses long-sized
> > >>> (8byte) st_*time sec/nsec components.
> > >>>
> > >>> (This is similar to the case of 32bit vs. 64bit RISCV: the original
> > >>> code does not use struct target_stat64 in 64bit RISCV env, when both
> > >>> TARGET_RISCV and TARGET_RISCV64 are defined.)
> > >>>
> > >>> This fix is important for LoongArch64 ABI1.0, where stat() is using an
> > >>> fstatat syscall with this struct target_stat64, if its usage is
> > >>> enabled.
> > >>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this
> > >>> problematic struct target_stat64 is not used, struct statx is correct
> > >>> in the LoongArch64 env.)
> > >>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371
> > >>>
> > >>> Signed-off-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> > >>> ---
> > >>>    linux-user/syscall_defs.h | 2 +-
> > >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> >

Re: [PATCH] linux-user: fix usage of struct target_stat64 for TARGET_LOONGARCH64 in syscall_defs.h

Posted by Gyorgy Tamasi 6 hours ago

> > This changeset was the last mod of syscall_defs.h - but it still
> > incorrectly modifies the condition of struct target_stat64 usage:
> > (~ "Add Loongarch64 old ABI support")
> > https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99
> > (line 2006)
> > -----
> > -#if !defined(TARGET_RISCV64)
> > +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed
> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.
> Huacai

But here the added "|| defined(TARGET_LOONGARCH64)" part doesn't fix
that affected bug similar to RISCV[32] vs. RISCV64...you need "&&
!defined(TARGET_LOONGARCH64)" here to create an effect for
TARGET_LOONGARCH64 similar to the proper solution for TARGET_RISCV64
(~ disable the use of this struct target_stat64 with 32bit sec/nsec
fields for a glibc environment where 64bit sec/nsecs are used - the
default struct target_stat is perfect for these 64bit envs, do not let
TARGET_HAS_STRUCT_STAT64 to be defined). [This 2nd embedded "||
defined(TARGET_LOONGARCH64)" within an other encapsulating "||
defined(TARGET_LOONGARCH64)" #elif-section is effectively a no-op here
(the 2nd is always true, if the encapsulating 1st was true)...it does
not effectively change the behaviour of its conditional
code-fragment-body in the actual context...comparing to the original
"#if !defined(TARGET_RISCV64)" full-line.]

How the contexts of LoongArch64 ABI1.0 vs. ABI2.0 are linked to this
issue (related to an optional code-path in qemu/linux-user/syscall.c)?
The answer:
The existence of this bug does not directly depend on or linked to any
difference of core features of LA64's ABI1.0 vs. ABI2.0.
The difference in behaviour of ABI1.0 and ABI2.0 environments related
to this qemu-code-part here strictly depends on the behaviour of
specific glibc versions used by those LA64 ABI1.0 and ABI2.0
environments.

In the ABI1.0 env of glibc-2.28-7cdc44d5a1 used by Loongson's gcc 8.3
rc1.6 a stat-like call (filling up a struct stat instance) IS NOT
always routed via the statx syscall, newfstatat can be used
instead!...and the processing of this newfstatat triggers the usage of
the problematic code-path in qemu/linux-user/syscall.c having this
bug, related to the host_to_target_stat64() function, where this code
fragment prefers to use struct target_stat64 (instead of struct
target_stat), if its use is enabled by
defined(TARGET_HAS_STRUCT_STAT64):
(~ around line 7975 in the 10.2.2 source)
#if defined(TARGET_HAS_STRUCT_STAT64)
        struct target_stat64 *target_st;
#else
        struct target_stat *target_st;
#endif

While in the ABI2.0 env of glibc of this gcc
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
from https://github.com/loongson/build-tools (glibc:
https://ftp.gnu.org/gnu/glibc/glibc-2.42.tar.xz) ALL stat-like calls
ARE ROUTED via the statx syscall, so the problematic code path of
host_to_target_stat64() IS NOT used/triggered at all (and processing
path of the statx syscall in linux-user/syscall.c is correct). This
behaviour of glibc-2.42 can be determined by these definitions in
glibc-2.42/sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h:
-----
/* To avoid the messy usage of the fstat, newfstatat, and statx system calls, we
only use statx.  */
#undef __NR_fstat
#undef __NR_newfstatat
-----

-tgy

On Sat, Apr 11, 2026 at 10:24 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> On Sat, Apr 11, 2026 at 10:09 AM Gyorgy Tamasi <gyorgy.tamasi@gmail.com> wrote:
> >
> > Hi,
> >
> > Thanks for the link of this separate Loongson-maintained 9.2-tcg-old
> > branch - intended for use specifically with ABI 1.0 code.
> >
> > This separate branch still contains the same bug (in the context of
> > the glibc-2.28-7cdc44d5a1 env of Loongson's gcc 8.3.0 rc1.6 - where
> > fstatat syscall can be used by glibc, and it can trigger the usage of
> > the related erroneous data-conversion workflow based on  struct
> > target_stat64 with 4byte sec/nsec fields):
> >
> > This changeset was the last mod of syscall_defs.h - but it still
> > incorrectly modifies the condition of struct target_stat64 usage:
> > (~ "Add Loongarch64 old ABI support")
> > https://github.com/loongson/qemu/commit/409f7717d6e3217cb8f497547bbe45c2e864be99
> > (line 2006)
> > -----
> > -#if !defined(TARGET_RISCV64)
> > +#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
> I think this patch has nothing to do with ABI 1.0/2.0, it really fixed
> a bug, similar to RISCV. While RISCV has no ABI 1.0/2.0.
>
> Huacai
>
> > -----
> >
> > This is the broader context in this 9.2-tcg-old original version:
> > Here the 2nd embedded "|| defined(TARGET_LOONGARCH64)" normally a
> > no-op: always true/false if the 1st "|| defined(TARGET_LOONGARCH64)"
> > is true/false.
> > -----
> > #elif defined(TARGET_OPENRISC) || defined(TARGET_NIOS2) \
> >         || defined(TARGET_RISCV) || defined(TARGET_HEXAGON) || \
> >         defined(TARGET_LOONGARCH64)
> > /* These are the asm-generic versions of the stat and stat64 structures */
> >
> > #define TARGET_STAT_HAVE_NSEC
> > struct target_stat {
> > ...
> > };
> >
> > #if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
> > #define TARGET_HAS_STRUCT_STAT64
> > struct target_stat64 {
> > ...
> > };
> > #endif
> >
> > #elif defined(TARGET_HPPA)
> > -----
> >
> > The correct fix is the same here (~ disable the use of this struct
> > target_stat64 - instead of explicitly enabling it for
> > TARGET_LOONGARCH64 with the "|| defined(...)" part):
> > -----
> > ~/qemu/qemu-9.2-tcg-old/linux-user$ diff -u syscall_defs.h.ori syscall_defs.h
> > --- syscall_defs.h.ori  2026-04-10 20:53:34.639034304 +0200
> > +++ syscall_defs.h      2026-04-10 20:55:12.219347804 +0200
> > @@ -2003,7 +2003,7 @@
> >      abi_uint __unused5;
> >  };
> >
> > -#if !defined(TARGET_RISCV64) || defined(TARGET_LOONGARCH64)
> > +#if !defined(TARGET_RISCV64) && !defined(TARGET_LOONGARCH64)
> >  #define TARGET_HAS_STRUCT_STAT64
> >  struct target_stat64 {
> >      abi_ullong st_dev;
> > -----
> >
> > The same test-scenario of
> > https://gitlab.com/qemu-project/qemu/-/work_items/3371 can be used
> > [with the relevant gcc 8.3 rc1.6 & this qemu linux-user 9.2-tcg-old
> > toolset] to show exactly the same bad & good test results - without &
> > with this mod.
> >
> > Just a personal experience based side-note on ABI1.0 compatibility
> > with mainline qemu (~10.2.2):
> > I'm working on porting a quite large code-base (a commercial OCR &
> > document conversion SDK) to LoongArch64 (for ABI1.0 and ABI2.0)...and
> > I'm trying to check correctness of my actual builds using the
> > regression-test package of this codebase. It runs quite complex
> > workflows of general CLI code. I accept that this is not a
> > comprehensive test with all of the edge cases or touching every
> > special areas (like signal handling) of compatibility of ABI1.0 and
> > mainline qemu, but...the ABI1.0 version of this test-code seems to be
> > able to run with mainline qemu-user 10.2.2.
> >
> > Best regards,
> > -tgy
> >
> > On Fri, Apr 10, 2026 at 11:37 AM gaosong <gaosong@loongson.cn> wrote:
> > >
> > > 在 2026/4/9 下午8:14, Gyorgy Tamasi 写道:
> > > > Tested-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> > > >
> > > > Additional independent testing (bug + fix cases) is documented here -
> > > > see comments by sourav/@kishu279:
> > > > https://gitlab.com/qemu-project/qemu/-/work_items/3371
> > >
> > > Hi.
> > > Please note that QEMU is not compatible with ABI 1.0.
> > >
> > > If you absolutely must use ABI 1.0, the branch below is the version we use.
> > > https://github.com/loongson/qemu/commits/9.2-tcg-old/
> > >
> > > However, this branch is quite far from the mainline.
> > > The QEMU mainline follows the kernel mainline, and
> > > I believe this is the case for other architectures as well.
> > >
> > > Thanks.
> > > Song Gao
> > > > On Wed, Apr 8, 2026 at 8:21 PM Pierrick Bouvier
> > > > <pierrick.bouvier@linaro.org> wrote:
> > > >> On 4/8/26 11:17 AM, Gyorgy Tamasi wrote:
> > > >>> In a 64bit LoongArch64 env (both TARGET_LOONGARCH and
> > > >>> TARGET_LOONGARCH64 are defined!) we can not use the struct
> > > >>> target_stat64 for data-transfer, since this struct target_stat64 is
> > > >>> defined for 32bit environments with its int-sized (4byte) st_*time
> > > >>> sec/nsec components.
> > > >>> The user side compiler headers of the LoongArch64 env uses long-sized
> > > >>> (8byte) st_*time sec/nsec components.
> > > >>>
> > > >>> (This is similar to the case of 32bit vs. 64bit RISCV: the original
> > > >>> code does not use struct target_stat64 in 64bit RISCV env, when both
> > > >>> TARGET_RISCV and TARGET_RISCV64 are defined.)
> > > >>>
> > > >>> This fix is important for LoongArch64 ABI1.0, where stat() is using an
> > > >>> fstatat syscall with this struct target_stat64, if its usage is
> > > >>> enabled.
> > > >>> (In case of LoongArch64 ABI2.0 stat() uses statx syscall, where this
> > > >>> problematic struct target_stat64 is not used, struct statx is correct
> > > >>> in the LoongArch64 env.)
> > > >>> See also: https://gitlab.com/qemu-project/qemu/-/work_items/3371
> > > >>>
> > > >>> Signed-off-by: Gyorgy Tamasi <gyorgy.tamasi@gmail.com>
> > > >>> ---
> > > >>>    linux-user/syscall_defs.h | 2 +-
> > > >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>
> > > >> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> > >