| Message ID | 20241011080253.2764887-2-caiyinyu@loongson.cn |
|---|---|
| State | New |
| Headers | show |
| Series | LoongArch: Regenerate loongarch/arch-syscall.h by build-many-glibcs.py update-syscalls. | expand |
*> Hi, there seems to be some mistake. > According to Florian Weimer's suggestion[0] and my testing, the purpose > of commit 255dc1e4ed8 [1] was to prevent build-many-glibcs.py > update-syscalls from adding __NR_fstat 80 and __NR_newfstatat 79 to > loongarch/arch-syscall.h, as we have currently decided not to use these > two syscalls to remain consistent with the previous implementation.(for > full discussion, see: > https://sourceware.org/pipermail/libc-alpha/2024-September/thread.html, > thread: [PATCH] LoongArch: Add fstat64 and fstatat64). > > However, I found that __NR_fstat 80 and __NR_newfstatat 79 were added to > loongarch/arch-syscall.h in commit > 02de16df481f15d5f6f2a8d98aa1bb2888aec13b [1]. This resulted in 79 and 80 > being used. > > I regenerate the loongarch/arch-syscall.h headers and send the patch > *assuming I am allowed to modify arch-syscall.h.* I think this change is correct. Adhemerval, how did you generate the arch-syscall.h update? With automatic generation, the presence of fixup-asm-unistd.h should have avoided adding these constants to arch-syscall.h. During the glibc build, fixup-asm-unistd.h is not used.
On 11/10/24 05:45, Florian Weimer wrote: > *> Hi, there seems to be some mistake. >> According to Florian Weimer's suggestion[0] and my testing, the purpose >> of commit 255dc1e4ed8 [1] was to prevent build-many-glibcs.py >> update-syscalls from adding __NR_fstat 80 and __NR_newfstatat 79 to >> loongarch/arch-syscall.h, as we have currently decided not to use these >> two syscalls to remain consistent with the previous implementation.(for >> full discussion, see: >> https://sourceware.org/pipermail/libc-alpha/2024-September/thread.html, >> thread: [PATCH] LoongArch: Add fstat64 and fstatat64). >> >> However, I found that __NR_fstat 80 and __NR_newfstatat 79 were added to >> loongarch/arch-syscall.h in commit >> 02de16df481f15d5f6f2a8d98aa1bb2888aec13b [1]. This resulted in 79 and 80 >> being used. >> >> I regenerate the loongarch/arch-syscall.h headers and send the patch >> *assuming I am allowed to modify arch-syscall.h.* > > I think this change is correct. > > Adhemerval, how did you generate the arch-syscall.h update? With > automatic generation, the presence of fixup-asm-unistd.h should have > avoided adding these constants to arch-syscall.h. During the glibc > build, fixup-asm-unistd.h is not used. I ran the usual update-syscall rule, but I might have missed this committed so I did not update the file correctly.
diff --git a/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h b/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h index 7e732256fd..8bb82448a7 100644 --- a/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h +++ b/sysdeps/unix/sysv/linux/loongarch/arch-syscall.h @@ -59,7 +59,6 @@ #define __NR_fsmount 432 #define __NR_fsopen 430 #define __NR_fspick 433 -#define __NR_fstat 80 #define __NR_fstatfs 44 #define __NR_fsync 82 #define __NR_ftruncate 46 @@ -167,7 +166,6 @@ #define __NR_munmap 215 #define __NR_name_to_handle_at 264 #define __NR_nanosleep 101 -#define __NR_newfstatat 79 #define __NR_nfsservctl 42 #define __NR_open_by_handle_at 265 #define __NR_open_tree 428
Hi, there seems to be some mistake. According to Florian Weimer's suggestion[0] and my testing, the purpose of commit 255dc1e4ed8 [1] was to prevent build-many-glibcs.py update-syscalls from adding __NR_fstat 80 and __NR_newfstatat 79 to loongarch/arch-syscall.h, as we have currently decided not to use these two syscalls to remain consistent with the previous implementation.(for full discussion, see: https://sourceware.org/pipermail/libc-alpha/2024-September/thread.html, thread: [PATCH] LoongArch: Add fstat64 and fstatat64). However, I found that __NR_fstat 80 and __NR_newfstatat 79 were added to loongarch/arch-syscall.h in commit 02de16df481f15d5f6f2a8d98aa1bb2888aec13b [1]. This resulted in 79 and 80 being used. I regenerate the loongarch/arch-syscall.h headers and send the patch *assuming I am allowed to modify arch-syscall.h.* [0] https://sourceware.org/pipermail/libc-alpha/2024-September/160103.html [1] commit 255dc1e4ed8b816919470633543b38a4428d9655 (offical/master) Author: caiyinyu <caiyinyu@loongson.cn> Date: Tue Sep 24 11:09:32 2024 +0800 LoongArch: Undef __NR_fstat and __NR_newfstatat. In Linux 6.11, fstat and newfstatat are added back. To avoid the messy usage of the fstat, newfstatat, and statx system calls, we will continue using statx only in glibc, maintaining consistency with previous versions of the LoongArch-specific glibc implementation. Signed-off-by: caiyinyu <caiyinyu@loongson.cn> Reviewed-by: Xi Ruoyao <xry111@xry111.site> Suggested-by: Florian Weimer <fweimer@redhat.com> sysdeps/unix/sysv/linux/loongarch/fixup-asm-unistd.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) [2] commit 02de16df481f15d5f6f2a8d98aa1bb2888aec13b Author: Adhemerval Zanella <adhemerval.zanella@linaro.org> Date: Tue Oct 8 15:45:24 2024 -0300 Update syscall lists for Linux 6.11 Linux 6.11 changes for syscall are: * fstat/newfstatat for loongarch (it should be safe to add since 255dc1e4ed8 that undefine them). * clone3 for nios2, which only adds the entry point but defined __ARCH_BROKEN_SYS_CLONE3 (the syscall will always return ENOSYS). * uretprobe for x86_64 and x32. --- sysdeps/unix/sysv/linux/loongarch/arch-syscall.h | 2 -- 1 file changed, 2 deletions(-)