* [musl] add loongarch64 port
@ 2022-03-22 3:52 王洪亮
2022-03-22 12:59 ` Rich Felker
` (2 more replies)
0 siblings, 3 replies; 52+ messages in thread
From: 王洪亮 @ 2022-03-22 3:52 UTC (permalink / raw)
To: musl; +Cc: liuxue, lvjianmin
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
Hi,
Thank you for give us some useful suggestions on the first submit
from 翟小娟 <zhaixiaojuan@loongson.cn>.
we review code and make changes on code specification, code style
and code errors.
The new patch has been published in
https://github.com/loongson/musl/tree/loongarch-v1.0.
The linux kernel has been published in
https://github.com/loongson/linux/tree/loongarch-next.
we alse published gcc, glibc in https://github.com/loongson
and submitting to the community.
we can supply a physical machine remote login for test musl.
It has been compiled and run the libc-test successfully.
Please code review, thanks!
Hongliang Wang
[-- Attachment #2: 0001-add-loongarch64-port.patch --]
[-- Type: text/x-patch, Size: 48849 bytes --]
From f5df725607675b370daec09a14ad130c792fa0d2 Mon Sep 17 00:00:00 2001
From: wanghongliang <wanghongliang@loongson.cn>
Date: Mon, 21 Mar 2022 06:13:20 +0800
Subject: [PATCH] add loongarch64 port.
Author: xiaojuanZhai <zhaixiaojuan@loongson.cn>
Author: meidanLi <limeidan@loongson.cn>
Author: guoqiChen <chenguoqi@loongson.cn>
Author: xiaolinZhao <zhaoxiaolin@loongson.cn>
Author: Fanpeng <fanpeng@loongson.cn>
Author: jiantaoShan <shanjiantao@loongson.cn>
Author: xuhuiQiang <qiangxuhui@loongson.cn>
Author: jingyunHua <huajingyun@loongson.cn>
Author: liuxue <liuxue@loongson.cn>
Author: wanghongliang <wanghongliang@loongson.cn>
Signed-off-by: wanghongliang <wanghongliang@loongson.cn>
---
arch/loongarch64/atomic_arch.h | 53 ++++
arch/loongarch64/bits/alltypes.h.in | 20 ++
arch/loongarch64/bits/fcntl.h | 40 +++
arch/loongarch64/bits/fenv.h | 20 ++
arch/loongarch64/bits/float.h | 16 ++
arch/loongarch64/bits/hwcap.h | 14 +
arch/loongarch64/bits/posix.h | 2 +
arch/loongarch64/bits/ptrace.h | 4 +
arch/loongarch64/bits/reg.h | 66 +++++
arch/loongarch64/bits/setjmp.h | 1 +
arch/loongarch64/bits/signal.h | 79 ++++++
arch/loongarch64/bits/stat.h | 20 ++
arch/loongarch64/bits/stdint.h | 20 ++
arch/loongarch64/bits/syscall.h.in | 307 +++++++++++++++++++++
arch/loongarch64/bits/user.h | 5 +
arch/loongarch64/crt_arch.h | 14 +
arch/loongarch64/kstat.h | 21 ++
arch/loongarch64/pthread_arch.h | 13 +
arch/loongarch64/reloc.h | 35 +++
arch/loongarch64/syscall_arch.h | 137 +++++++++
configure | 1 +
crt/loongarch64/crti.s | 15 +
crt/loongarch64/crtn.s | 12 +
include/elf.h | 66 +++++
src/fenv/loongarch64/fenv.S | 72 +++++
src/ldso/loongarch64/dlsym.s | 12 +
src/setjmp/loongarch64/longjmp.S | 37 +++
src/setjmp/loongarch64/setjmp.S | 34 +++
src/signal/loongarch64/restore.s | 10 +
src/signal/loongarch64/sigsetjmp.s | 29 ++
src/thread/loongarch64/__set_thread_area.s | 7 +
src/thread/loongarch64/__unmapself.s | 7 +
src/thread/loongarch64/clone.s | 28 ++
src/thread/loongarch64/syscall_cp.s | 29 ++
34 files changed, 1246 insertions(+)
create mode 100644 arch/loongarch64/atomic_arch.h
create mode 100644 arch/loongarch64/bits/alltypes.h.in
create mode 100644 arch/loongarch64/bits/fcntl.h
create mode 100644 arch/loongarch64/bits/fenv.h
create mode 100644 arch/loongarch64/bits/float.h
create mode 100644 arch/loongarch64/bits/hwcap.h
create mode 100644 arch/loongarch64/bits/posix.h
create mode 100644 arch/loongarch64/bits/ptrace.h
create mode 100644 arch/loongarch64/bits/reg.h
create mode 100644 arch/loongarch64/bits/setjmp.h
create mode 100644 arch/loongarch64/bits/signal.h
create mode 100644 arch/loongarch64/bits/stat.h
create mode 100644 arch/loongarch64/bits/stdint.h
create mode 100644 arch/loongarch64/bits/syscall.h.in
create mode 100644 arch/loongarch64/bits/user.h
create mode 100644 arch/loongarch64/crt_arch.h
create mode 100644 arch/loongarch64/kstat.h
create mode 100644 arch/loongarch64/pthread_arch.h
create mode 100644 arch/loongarch64/reloc.h
create mode 100644 arch/loongarch64/syscall_arch.h
create mode 100644 crt/loongarch64/crti.s
create mode 100644 crt/loongarch64/crtn.s
create mode 100644 src/fenv/loongarch64/fenv.S
create mode 100644 src/ldso/loongarch64/dlsym.s
create mode 100644 src/setjmp/loongarch64/longjmp.S
create mode 100644 src/setjmp/loongarch64/setjmp.S
create mode 100644 src/signal/loongarch64/restore.s
create mode 100644 src/signal/loongarch64/sigsetjmp.s
create mode 100644 src/thread/loongarch64/__set_thread_area.s
create mode 100644 src/thread/loongarch64/__unmapself.s
create mode 100644 src/thread/loongarch64/clone.s
create mode 100644 src/thread/loongarch64/syscall_cp.s
diff --git a/arch/loongarch64/atomic_arch.h b/arch/loongarch64/atomic_arch.h
new file mode 100644
index 00000000..bf4805c9
--- /dev/null
+++ b/arch/loongarch64/atomic_arch.h
@@ -0,0 +1,53 @@
+#define a_ll a_ll
+static inline int a_ll(volatile int *p)
+{
+ int v;
+ __asm__ __volatile__ (
+ "ll.w %0, %1"
+ : "=r"(v)
+ : "ZC"(*p));
+ return v;
+}
+
+#define a_sc a_sc
+static inline int a_sc(volatile int *p, int v)
+{
+ int r;
+ __asm__ __volatile__ (
+ "sc.w %0, %1"
+ : "=r"(r), "=ZC"(*p)
+ : "0"(v) : "memory");
+ return r;
+}
+
+#define a_ll_p a_ll_p
+static inline void *a_ll_p(volatile void *p)
+{
+ void *v;
+ __asm__ __volatile__ (
+ "ll.d %0, %1"
+ : "=r"(v)
+ : "ZC"(*(void *volatile *)p));
+ return v;
+}
+
+#define a_sc_p a_sc_p
+static inline int a_sc_p(volatile void *p, void *v)
+{
+ long r;
+ __asm__ __volatile__ (
+ "sc.d %0, %1"
+ : "=r"(r), "=ZC"(*(void *volatile *)p)
+ : "0"(v)
+ : "memory");
+ return r;
+}
+
+#define a_barrier a_barrier
+static inline void a_barrier()
+{
+ __asm__ __volatile__ ("dbar 0" : : : "memory");
+}
+
+#define a_pre_llsc a_barrier
+#define a_post_llsc a_barrier
diff --git a/arch/loongarch64/bits/alltypes.h.in b/arch/loongarch64/bits/alltypes.h.in
new file mode 100644
index 00000000..38871b5f
--- /dev/null
+++ b/arch/loongarch64/bits/alltypes.h.in
@@ -0,0 +1,20 @@
+#define _Addr long
+#define _Int64 long
+#define _Reg long
+
+#define __BYTE_ORDER 1234
+#define __LONG_MAX 0x7fffffffffffffffL
+
+TYPEDEF __builtin_va_list va_list;
+TYPEDEF __builtin_va_list __isoc_va_list;
+
+#ifndef __cplusplus
+TYPEDEF int wchar_t;
+#endif
+
+TYPEDEF float float_t;
+TYPEDEF double double_t;
+
+TYPEDEF struct { long long __ll; long double __ld; } max_align_t;
+
+TYPEDEF unsigned nlink_t;
diff --git a/arch/loongarch64/bits/fcntl.h b/arch/loongarch64/bits/fcntl.h
new file mode 100644
index 00000000..9bcbb7ff
--- /dev/null
+++ b/arch/loongarch64/bits/fcntl.h
@@ -0,0 +1,40 @@
+#define O_CREAT 0100
+#define O_EXCL 0200
+#define O_NOCTTY 0400
+#define O_TRUNC 01000
+#define O_APPEND 02000
+#define O_NONBLOCK 04000
+#define O_DSYNC 010000
+#define O_SYNC 04010000
+#define O_RSYNC 04010000
+#define O_DIRECTORY 0200000
+#define O_NOFOLLOW 0400000
+#define O_CLOEXEC 02000000
+
+#define O_ASYNC 020000
+#define O_DIRECT 040000
+#define O_LARGEFILE 0100000
+#define O_NOATIME 01000000
+#define O_PATH 010000000
+#define O_TMPFILE 020000000
+#define O_NDELAY O_NONBLOCK
+
+#define F_DUPFD 0
+#define F_GETFD 1
+#define F_SETFD 2
+#define F_GETFL 3
+#define F_SETFL 4
+
+#define F_SETOWN 8
+#define F_GETOWN 9
+#define F_SETSIG 10
+#define F_GETSIG 11
+
+#define F_GETLK 5
+#define F_SETLK 6
+#define F_SETLKW 7
+
+#define F_SETOWN_EX 15
+#define F_GETOWN_EX 16
+
+#define F_GETOWNER_UIDS 17
diff --git a/arch/loongarch64/bits/fenv.h b/arch/loongarch64/bits/fenv.h
new file mode 100644
index 00000000..264cafb5
--- /dev/null
+++ b/arch/loongarch64/bits/fenv.h
@@ -0,0 +1,20 @@
+#define FE_INEXACT 0x010000
+#define FE_UNDERFLOW 0x020000
+#define FE_OVERFLOW 0x040000
+#define FE_DIVBYZERO 0x080000
+#define FE_INVALID 0x100000
+
+#define FE_ALL_EXCEPT 0x1F0000
+
+#define FE_TONEAREST 0x000
+#define FE_TOWARDZERO 0x100
+#define FE_UPWARD 0x200
+#define FE_DOWNWARD 0x300
+
+typedef unsigned fexcept_t;
+
+typedef struct {
+ unsigned __cw;
+} fenv_t;
+
+#define FE_DFL_ENV ((const fenv_t *) -1)
diff --git a/arch/loongarch64/bits/float.h b/arch/loongarch64/bits/float.h
new file mode 100644
index 00000000..719c7908
--- /dev/null
+++ b/arch/loongarch64/bits/float.h
@@ -0,0 +1,16 @@
+#define FLT_EVAL_METHOD 0
+
+#define LDBL_TRUE_MIN 6.47517511943802511092443895822764655e-4966L
+#define LDBL_MIN 3.36210314311209350626267781732175260e-4932L
+#define LDBL_MAX 1.18973149535723176508575932662800702e+4932L
+#define LDBL_EPSILON 1.92592994438723585305597794258492732e-34L
+
+#define LDBL_MANT_DIG 113
+#define LDBL_MIN_EXP (-16381)
+#define LDBL_MAX_EXP 16384
+
+#define LDBL_DIG 33
+#define LDBL_MIN_10_EXP (-4931)
+#define LDBL_MAX_10_EXP 4932
+
+#define DECIMAL_DIG 36
diff --git a/arch/loongarch64/bits/hwcap.h b/arch/loongarch64/bits/hwcap.h
new file mode 100644
index 00000000..c9fa08f6
--- /dev/null
+++ b/arch/loongarch64/bits/hwcap.h
@@ -0,0 +1,14 @@
+/* HWCAP - Hardware Capabilities.
+ * Hardware information is not clear at present, leave it blank.
+ */
+#define HWCAP_LOONGARCH_CPUCFG (1 << 0)
+#define HWCAP_LOONGARCH_FPU (1 << 1)
+#define HWCAP_LOONGARCH_LSX (1 << 2) /* support 128bit vectors*/
+#define HWCAP_LOONGARCH_LASX (1 << 3) /* support 256bit vectors*/
+#define HWCAP_LOONGARCH_LBT (1 << 4) /* support LBT*/
+#define HWCAP_LOONGARCH_LVZ (1 << 5) /* support virtualization expansion*/
+#define HWCAP_LOONGARCH_CRC32 (1 << 7) /* support CRC32 check*/
+#define HWCAP_LOONGARCH_AES (1 << 6)
+#define HWCAP_LOONGARCH_SHA1 (1 << 8)
+#define HWCAP_LOONGARCH_SHA2 (1 << 9)
+#define HWCAP_LOONGARCH_SHA3 (1 << 10)
diff --git a/arch/loongarch64/bits/posix.h b/arch/loongarch64/bits/posix.h
new file mode 100644
index 00000000..8068ce98
--- /dev/null
+++ b/arch/loongarch64/bits/posix.h
@@ -0,0 +1,2 @@
+#define _POSIX_V6_LP64_OFF64 1
+#define _POSIX_V7_LP64_OFF64 1
diff --git a/arch/loongarch64/bits/ptrace.h b/arch/loongarch64/bits/ptrace.h
new file mode 100644
index 00000000..741fc668
--- /dev/null
+++ b/arch/loongarch64/bits/ptrace.h
@@ -0,0 +1,4 @@
+#define PTRACE_GET_THREAD_AREA 25
+#define PTRACE_SET_THREAD_AREA 26
+#define PTRACE_GET_WATCH_REGS 0xd0
+#define PTRACE_SET_WATCH_REGS 0xd1
diff --git a/arch/loongarch64/bits/reg.h b/arch/loongarch64/bits/reg.h
new file mode 100644
index 00000000..5d3f92c5
--- /dev/null
+++ b/arch/loongarch64/bits/reg.h
@@ -0,0 +1,66 @@
+#undef __WORDSIZE
+#define __WORDSIZE 64
+#define LOONGARCH64_EF_R0 0
+#define LOONGARCH64_EF_R1 1
+#define LOONGARCH64_EF_R2 2
+#define LOONGARCH64_EF_R3 3
+#define LOONGARCH64_EF_R4 4
+#define LOONGARCH64_EF_R5 5
+#define LOONGARCH64_EF_R6 6
+#define LOONGARCH64_EF_R7 7
+#define LOONGARCH64_EF_R8 8
+#define LOONGARCH64_EF_R9 9
+#define LOONGARCH64_EF_R10 10
+#define LOONGARCH64_EF_R11 11
+#define LOONGARCH64_EF_R12 12
+#define LOONGARCH64_EF_R13 13
+#define LOONGARCH64_EF_R14 14
+#define LOONGARCH64_EF_R15 15
+#define LOONGARCH64_EF_R16 16
+#define LOONGARCH64_EF_R17 17
+#define LOONGARCH64_EF_R18 18
+#define LOONGARCH64_EF_R19 19
+#define LOONGARCH64_EF_R20 20
+#define LOONGARCH64_EF_R21 21
+#define LOONGARCH64_EF_R22 22
+#define LOONGARCH64_EF_R23 23
+#define LOONGARCH64_EF_R24 24
+#define LOONGARCH64_EF_R25 25
+#define LOONGARCH64_EF_R26 26
+#define LOONGARCH64_EF_R27 27
+#define LOONGARCH64_EF_R28 28
+#define LOONGARCH64_EF_R29 29
+#define LOONGARCH64_EF_R30 30
+#define LOONGARCH64_EF_R31 31
+
+#define LOONGARCH64_EF_SIZE 304 /* size in bytes */
+
+#define EF_R0 LOONGARCH64_EF_R0
+#define EF_R1 LOONGARCH64_EF_R1
+#define EF_R2 LOONGARCH64_EF_R2
+#define EF_R3 LOONGARCH64_EF_R3
+#define EF_R4 LOONGARCH64_EF_R4
+#define EF_R5 LOONGARCH64_EF_R5
+#define EF_R6 LOONGARCH64_EF_R6
+#define EF_R7 LOONGARCH64_EF_R7
+#define EF_R8 LOONGARCH64_EF_R8
+#define EF_R9 LOONGARCH64_EF_R9
+#define EF_R10 LOONGARCH64_EF_R10
+#define EF_R11 LOONGARCH64_EF_R11
+#define EF_R12 LOONGARCH64_EF_R12
+#define EF_R13 LOONGARCH64_EF_R13
+#define EF_R14 LOONGARCH64_EF_R14
+#define EF_R15 LOONGARCH64_EF_R15
+#define EF_R16 LOONGARCH64_EF_R16
+#define EF_R17 LOONGARCH64_EF_R17
+#define EF_R18 LOONGARCH64_EF_R18
+#define EF_R19 LOONGARCH64_EF_R19
+#define EF_R20 LOONGARCH64_EF_R20
+#define EF_R21 LOONGARCH64_EF_R21
+#define EF_R22 LOONGARCH64_EF_R22
+#define EF_R23 LOONGARCH64_EF_R23
+#define EF_R24 LOONGARCH64_EF_R24
+#define EF_R25 LOONGARCH64_EF_R25
+#define EF_R26 LOONGARCH64_EF_R26
+#define EF_R27 LOONGARCH64_EF_R27
+#define EF_R28 LOONGARCH64_EF_R28
diff --git a/arch/loongarch64/bits/setjmp.h b/arch/loongarch64/bits/setjmp.h
new file mode 100644
index 00000000..f4a7f8a3
--- /dev/null
+++ b/arch/loongarch64/bits/setjmp.h
@@ -0,0 +1 @@
+typedef unsigned long long __jmp_buf[22];
diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
new file mode 100644
index 00000000..a28ec91a
--- /dev/null
+++ b/arch/loongarch64/bits/signal.h
@@ -0,0 +1,79 @@
+#if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
+ || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
+
+#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
+#define MINSIGSTKSZ 4096
+#define SIGSTKSZ 16384
+#endif
+
+typedef unsigned long greg_t, gregset_t[32];
+
+typedef struct sigcontext {
+ unsigned long pc;
+ gregset_t gregs;
+ unsigned int flags;
+ unsigned long extcontext[0] __attribute__((__aligned__(16)));
+}mcontext_t;
+
+struct sigaltstack {
+ void *ss_sp;
+ int ss_flags;
+ size_t ss_size;
+};
+
+typedef struct __ucontext
+{
+ unsigned long uc_flags;
+ struct __ucontext *uc_link;
+ stack_t uc_stack;
+ sigset_t uc_sigmask;
+ mcontext_t uc_mcontext;
+} ucontext_t;
+
+#define SA_NOCLDSTOP 1
+#define SA_NOCLDWAIT 2
+#define SA_SIGINFO 4
+#define SA_ONSTACK 0x08000000
+#define SA_RESTART 0x10000000
+#define SA_NODEFER 0x40000000
+#define SA_RESETHAND 0x80000000
+#define SA_RESTORER 0x04000000
+
+#endif
+
+#define SIGHUP 1
+#define SIGINT 2
+#define SIGQUIT 3
+#define SIGILL 4
+#define SIGTRAP 5
+#define SIGABRT 6
+#define SIGIOT SIGABRT
+#define SIGBUS 7
+#define SIGFPE 8
+#define SIGKILL 9
+#define SIGUSR1 10
+#define SIGSEGV 11
+#define SIGUSR2 12
+#define SIGPIPE 13
+#define SIGALRM 14
+#define SIGTERM 15
+#define SIGSTKFLT 16
+#define SIGCHLD 17
+#define SIGCONT 18
+#define SIGSTOP 19
+#define SIGTSTP 20
+#define SIGTTIN 21
+#define SIGTTOU 22
+#define SIGURG 23
+#define SIGXCPU 24
+#define SIGXFSZ 25
+#define SIGVTALRM 26
+#define SIGPROF 27
+#define SIGWINCH 28
+#define SIGIO 29
+#define SIGPOLL SIGIO
+#define SIGPWR 30
+#define SIGSYS 31
+#define SIGUNUSED SIGSYS
+
+#define _NSIG 64
diff --git a/arch/loongarch64/bits/stat.h b/arch/loongarch64/bits/stat.h
new file mode 100644
index 00000000..b620e142
--- /dev/null
+++ b/arch/loongarch64/bits/stat.h
@@ -0,0 +1,20 @@
+struct stat {
+ dev_t st_dev;
+ int __pad1[3];
+ ino_t st_ino;
+ mode_t st_mode;
+ nlink_t st_nlink;
+ uid_t st_uid;
+ gid_t st_gid;
+ dev_t st_rdev;
+ unsigned int __pad2[2];
+ off_t st_size;
+ int __pad3;
+ struct timespec st_atim;
+ struct timespec st_mtim;
+ struct timespec st_ctim;
+ blksize_t st_blksize;
+ unsigned int __pad4;
+ blkcnt_t st_blocks;
+ int __pad5[14];
+};
diff --git a/arch/loongarch64/bits/stdint.h b/arch/loongarch64/bits/stdint.h
new file mode 100644
index 00000000..1bb147f2
--- /dev/null
+++ b/arch/loongarch64/bits/stdint.h
@@ -0,0 +1,20 @@
+typedef int32_t int_fast16_t;
+typedef int32_t int_fast32_t;
+typedef uint32_t uint_fast16_t;
+typedef uint32_t uint_fast32_t;
+
+#define INT_FAST16_MIN INT32_MIN
+#define INT_FAST32_MIN INT32_MIN
+
+#define INT_FAST16_MAX INT32_MAX
+#define INT_FAST32_MAX INT32_MAX
+
+#define UINT_FAST16_MAX UINT32_MAX
+#define UINT_FAST32_MAX UINT32_MAX
+
+#define INTPTR_MIN INT64_MIN
+#define INTPTR_MAX INT64_MAX
+#define UINTPTR_MAX UINT64_MAX
+#define PTRDIFF_MIN INT64_MIN
+#define PTRDIFF_MAX INT64_MAX
+#define SIZE_MAX UINT64_MAX
diff --git a/arch/loongarch64/bits/syscall.h.in b/arch/loongarch64/bits/syscall.h.in
new file mode 100644
index 00000000..1f2c924a
--- /dev/null
+++ b/arch/loongarch64/bits/syscall.h.in
@@ -0,0 +1,307 @@
+#define __NR_io_setup 0
+#define __NR_io_destroy 1
+#define __NR_io_submit 2
+#define __NR_io_cancel 3
+#define __NR_io_getevents 4
+#define __NR_setxattr 5
+#define __NR_lsetxattr 6
+#define __NR_fsetxattr 7
+#define __NR_getxattr 8
+#define __NR_lgetxattr 9
+#define __NR_fgetxattr 10
+#define __NR_listxattr 11
+#define __NR_llistxattr 12
+#define __NR_flistxattr 13
+#define __NR_removexattr 14
+#define __NR_lremovexattr 15
+#define __NR_fremovexattr 16
+#define __NR_getcwd 17
+#define __NR_lookup_dcookie 18
+#define __NR_eventfd2 19
+#define __NR_epoll_create1 20
+#define __NR_epoll_ctl 21
+#define __NR_epoll_pwait 22
+#define __NR_dup 23
+#define __NR_dup3 24
+#define __NR3264_fcntl 25
+#define __NR_inotify_init1 26
+#define __NR_inotify_add_watch 27
+#define __NR_inotify_rm_watch 28
+#define __NR_ioctl 29
+#define __NR_ioprio_set 30
+#define __NR_ioprio_get 31
+#define __NR_flock 32
+#define __NR_mknodat 33
+#define __NR_mkdirat 34
+#define __NR_unlinkat 35
+#define __NR_symlinkat 36
+#define __NR_linkat 37
+#define __NR_umount2 39
+#define __NR_mount 40
+#define __NR_pivot_root 41
+#define __NR_nfsservctl 42
+#define __NR3264_statfs 43
+#define __NR3264_fstatfs 44
+#define __NR3264_truncate 45
+#define __NR3264_ftruncate 46
+#define __NR_fallocate 47
+#define __NR_faccessat 48
+#define __NR_chdir 49
+#define __NR_fchdir 50
+#define __NR_chroot 51
+#define __NR_fchmod 52
+#define __NR_fchmodat 53
+#define __NR_fchownat 54
+#define __NR_fchown 55
+#define __NR_openat 56
+#define __NR_close 57
+#define __NR_vhangup 58
+#define __NR_pipe2 59
+#define __NR_quotactl 60
+#define __NR_getdents64 61
+#define __NR3264_lseek 62
+#define __NR_read 63
+#define __NR_write 64
+#define __NR_readv 65
+#define __NR_writev 66
+#define __NR_pread64 67
+#define __NR_pwrite64 68
+#define __NR_preadv 69
+#define __NR_pwritev 70
+#define __NR3264_sendfile 71
+#define __NR_pselect6 72
+#define __NR_ppoll 73
+#define __NR_signalfd4 74
+#define __NR_vmsplice 75
+#define __NR_splice 76
+#define __NR_tee 77
+#define __NR_readlinkat 78
+#define __NR3264_fstatat 79
+#define __NR3264_fstat 80
+#define __NR_sync 81
+#define __NR_fsync 82
+#define __NR_fdatasync 83
+#define __NR_sync_file_range 84
+#define __NR_timerfd_create 85
+#define __NR_timerfd_settime 86
+#define __NR_timerfd_gettime 87
+#define __NR_utimensat 88
+#define __NR_acct 89
+#define __NR_capget 90
+#define __NR_capset 91
+#define __NR_personality 92
+#define __NR_exit 93
+#define __NR_exit_group 94
+#define __NR_waitid 95
+#define __NR_set_tid_address 96
+#define __NR_unshare 97
+#define __NR_futex 98
+#define __NR_set_robust_list 99
+#define __NR_get_robust_list 100
+#define __NR_nanosleep 101
+#define __NR_getitimer 102
+#define __NR_setitimer 103
+#define __NR_kexec_load 104
+#define __NR_init_module 105
+#define __NR_delete_module 106
+#define __NR_timer_create 107
+#define __NR_timer_gettime 108
+#define __NR_timer_getoverrun 109
+#define __NR_timer_settime 110
+#define __NR_timer_delete 111
+#define __NR_clock_settime 112
+#define __NR_clock_gettime 113
+#define __NR_clock_getres 114
+#define __NR_clock_nanosleep 115
+#define __NR_syslog 116
+#define __NR_ptrace 117
+#define __NR_sched_setparam 118
+#define __NR_sched_setscheduler 119
+#define __NR_sched_getscheduler 120
+#define __NR_sched_getparam 121
+#define __NR_sched_setaffinity 122
+#define __NR_sched_getaffinity 123
+#define __NR_sched_yield 124
+#define __NR_sched_get_priority_max 125
+#define __NR_sched_get_priority_min 126
+#define __NR_sched_rr_get_interval 127
+#define __NR_restart_syscall 128
+#define __NR_kill 129
+#define __NR_tkill 130
+#define __NR_tgkill 131
+#define __NR_sigaltstack 132
+#define __NR_rt_sigsuspend 133
+#define __NR_rt_sigaction 134
+#define __NR_rt_sigprocmask 135
+#define __NR_rt_sigpending 136
+#define __NR_rt_sigtimedwait 137
+#define __NR_rt_sigqueueinfo 138
+#define __NR_rt_sigreturn 139
+#define __NR_setpriority 140
+#define __NR_getpriority 141
+#define __NR_reboot 142
+#define __NR_setregid 143
+#define __NR_setgid 144
+#define __NR_setreuid 145
+#define __NR_setuid 146
+#define __NR_setresuid 147
+#define __NR_getresuid 148
+#define __NR_setresgid 149
+#define __NR_getresgid 150
+#define __NR_setfsuid 151
+#define __NR_setfsgid 152
+#define __NR_times 153
+#define __NR_setpgid 154
+#define __NR_getpgid 155
+#define __NR_getsid 156
+#define __NR_setsid 157
+#define __NR_getgroups 158
+#define __NR_setgroups 159
+#define __NR_uname 160
+#define __NR_sethostname 161
+#define __NR_setdomainname 162
+#define __NR_getrlimit 163
+#define __NR_setrlimit 164
+#define __NR_getrusage 165
+#define __NR_umask 166
+#define __NR_prctl 167
+#define __NR_getcpu 168
+#define __NR_gettimeofday 169
+#define __NR_settimeofday 170
+#define __NR_adjtimex 171
+#define __NR_getpid 172
+#define __NR_getppid 173
+#define __NR_getuid 174
+#define __NR_geteuid 175
+#define __NR_getgid 176
+#define __NR_getegid 177
+#define __NR_gettid 178
+#define __NR_sysinfo 179
+#define __NR_mq_open 180
+#define __NR_mq_unlink 181
+#define __NR_mq_timedsend 182
+#define __NR_mq_timedreceive 183
+#define __NR_mq_notify 184
+#define __NR_mq_getsetattr 185
+#define __NR_msgget 186
+#define __NR_msgctl 187
+#define __NR_msgrcv 188
+#define __NR_msgsnd 189
+#define __NR_semget 190
+#define __NR_semctl 191
+#define __NR_semtimedop 192
+#define __NR_semop 193
+#define __NR_shmget 194
+#define __NR_shmctl 195
+#define __NR_shmat 196
+#define __NR_shmdt 197
+#define __NR_socket 198
+#define __NR_socketpair 199
+#define __NR_bind 200
+#define __NR_listen 201
+#define __NR_accept 202
+#define __NR_connect 203
+#define __NR_getsockname 204
+#define __NR_getpeername 205
+#define __NR_sendto 206
+#define __NR_recvfrom 207
+#define __NR_setsockopt 208
+#define __NR_getsockopt 209
+#define __NR_shutdown 210
+#define __NR_sendmsg 211
+#define __NR_recvmsg 212
+#define __NR_readahead 213
+#define __NR_brk 214
+#define __NR_munmap 215
+#define __NR_mremap 216
+#define __NR_add_key 217
+#define __NR_request_key 218
+#define __NR_keyctl 219
+#define __NR_clone 220
+#define __NR_execve 221
+#define __NR3264_mmap 222
+#define __NR3264_fadvise64 223
+#define __NR_swapon 224
+#define __NR_swapoff 225
+#define __NR_mprotect 226
+#define __NR_msync 227
+#define __NR_mlock 228
+#define __NR_munlock 229
+#define __NR_mlockall 230
+#define __NR_munlockall 231
+#define __NR_mincore 232
+#define __NR_madvise 233
+#define __NR_remap_file_pages 234
+#define __NR_mbind 235
+#define __NR_get_mempolicy 236
+#define __NR_set_mempolicy 237
+#define __NR_migrate_pages 238
+#define __NR_move_pages 239
+#define __NR_rt_tgsigqueueinfo 240
+#define __NR_perf_event_open 241
+#define __NR_accept4 242
+#define __NR_recvmmsg 243
+#define __NR_arch_specific_syscall 244
+#define __NR_wait4 260
+#define __NR_prlimit64 261
+#define __NR_fanotify_init 262
+#define __NR_fanotify_mark 263
+#define __NR_name_to_handle_at 264
+#define __NR_open_by_handle_at 265
+#define __NR_clock_adjtime 266
+#define __NR_syncfs 267
+#define __NR_setns 268
+#define __NR_sendmmsg 269
+#define __NR_process_vm_readv 270
+#define __NR_process_vm_writev 271
+#define __NR_kcmp 272
+#define __NR_finit_module 273
+#define __NR_sched_setattr 274
+#define __NR_sched_getattr 275
+#define __NR_renameat2 276
+#define __NR_seccomp 277
+#define __NR_getrandom 278
+#define __NR_memfd_create 279
+#define __NR_bpf 280
+#define __NR_execveat 281
+#define __NR_userfaultfd 282
+#define __NR_membarrier 283
+#define __NR_mlock2 284
+#define __NR_copy_file_range 285
+#define __NR_preadv2 286
+#define __NR_pwritev2 287
+#define __NR_pkey_mprotect 288
+#define __NR_pkey_alloc 289
+#define __NR_pkey_free 290
+#define __NR_statx 291
+#define __NR_io_pgetevents 292
+#define __NR_rseq 293
+#define __NR_kexec_file_load 294
+#define __NR_pidfd_send_signal 424
+#define __NR_io_uring_setup 425
+#define __NR_io_uring_enter 426
+#define __NR_io_uring_register 427
+#define __NR_open_tree 428
+#define __NR_move_mount 429
+#define __NR_fsopen 430
+#define __NR_fsconfig 431
+#define __NR_fsmount 432
+#define __NR_fspick 433
+#define __NR_pidfd_open 434
+#define __NR_clone3 435
+#define __NR_close_range 436
+#define __NR_openat2 437
+#define __NR_pidfd_getfd 438
+#define __NR_faccessat2 439
+#define __NR_process_madvise 440
+#define __NR_fcntl __NR3264_fcntl
+#define __NR_statfs __NR3264_statfs
+#define __NR_fstatfs __NR3264_fstatfs
+#define __NR_truncate __NR3264_truncate
+#define __NR_ftruncate __NR3264_ftruncate
+#define __NR_lseek __NR3264_lseek
+#define __NR_sendfile __NR3264_sendfile
+#define __NR_newfstatat __NR3264_fstatat
+#define __NR_fstat __NR3264_fstat
+#define __NR_mmap __NR3264_mmap
+#define __NR_fadvise64 __NR3264_fadvise64
diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
new file mode 100644
index 00000000..4d4cd534
--- /dev/null
+++ b/arch/loongarch64/bits/user.h
@@ -0,0 +1,5 @@
+#define ELF_NGREG 45
+#define ELF_NFPREG 33
+
+typedef unsigned long elf_greg_t, elf_gregset_t[ELF_NGREG];
+typedef double elf_fpreg_t, elf_fpregset_t[ELF_NFPREG];
diff --git a/arch/loongarch64/crt_arch.h b/arch/loongarch64/crt_arch.h
new file mode 100644
index 00000000..c806a0bf
--- /dev/null
+++ b/arch/loongarch64/crt_arch.h
@@ -0,0 +1,14 @@
+__asm__(
+".text \n"
+".global " START "\n"
+".type " START ", @function\n"
+START ":\n"
+" add.w $fp, $r0,$r0\n"
+" or $a0, $sp, $zero\n"
+".weak _DYNAMIC\n"
+".hidden _DYNAMIC\n"
+" la.local $a1, _DYNAMIC\n"
+" addi.w $t7, $r0, -16\n"
+" and $sp, $sp, $t7\n"
+" b " START "_c\n"
+);
diff --git a/arch/loongarch64/kstat.h b/arch/loongarch64/kstat.h
new file mode 100644
index 00000000..4e39ffac
--- /dev/null
+++ b/arch/loongarch64/kstat.h
@@ -0,0 +1,21 @@
+struct kstat {
+ dev_t st_dev;
+ ino_t st_ino;
+ mode_t st_mode;
+ nlink_t st_nlink;
+ uid_t st_uid;
+ gid_t st_gid;
+ dev_t st_rdev;
+ unsigned long __pad1;
+ off_t st_size;
+ unsigned st_blksize;
+ int __pad2;
+ blkcnt_t st_blocks;
+ long st_atime_sec;
+ unsigned long st_atime_nsec;
+ long st_mtime_sec;
+ unsigned long st_mtime_nsec;
+ long st_ctime_sec;
+ unsigned long st_ctime_nsec;
+ unsigned __unused[2];
+};
diff --git a/arch/loongarch64/pthread_arch.h b/arch/loongarch64/pthread_arch.h
new file mode 100644
index 00000000..27f50e4c
--- /dev/null
+++ b/arch/loongarch64/pthread_arch.h
@@ -0,0 +1,13 @@
+static inline uintptr_t __get_tp()
+{
+ uintptr_t tp;
+ __asm__ ("or %0, $tp, $zero" : "=r" (tp) );
+ return tp;
+}
+
+#define TLS_ABOVE_TP
+#define GAP_ABOVE_TP 0
+
+#define DTP_OFFSET 0
+
+#define MC_PC pc
diff --git a/arch/loongarch64/reloc.h b/arch/loongarch64/reloc.h
new file mode 100644
index 00000000..249cb40c
--- /dev/null
+++ b/arch/loongarch64/reloc.h
@@ -0,0 +1,35 @@
+#ifndef __RELOC_H__
+#define __RELOC_H__
+
+#define _GNU_SOURCE
+#include <endian.h>
+
+#ifdef __loongarch64_soft_float
+#define FP_SUFFIX "-sf"
+#else
+#define FP_SUFFIX ""
+#endif
+
+#define LDSO_ARCH "loongarch64" FP_SUFFIX
+
+#define TPOFF_K (0x0)
+
+#define REL_PLT R_LARCH_JUMP_SLOT
+#define REL_COPY R_LARCH_COPY
+#define REL_DTPMOD R_LARCH_TLS_DTPMOD64
+#define REL_DTPOFF R_LARCH_TLS_DTPREL64
+#define REL_TPOFF R_LARCH_TLS_TPREL64
+#define REL_RELATIVE R_LARCH_RELATIVE
+#define REL_SYMBOLIC R_LARCH_64
+
+#define CRTJMP(pc,sp) __asm__ __volatile__( \
+ "move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
+
+#define GETFUNCSYM(fp, sym, got) __asm__ ( \
+ ".hidden " #sym "\n" \
+ ".align 8 \n" \
+ " la.local $t1, "#sym" \n" \
+ " or %0, $t1, $zero \n" \
+ : "=r"(*(fp)) : : "memory" )
+
+#endif
diff --git a/arch/loongarch64/syscall_arch.h b/arch/loongarch64/syscall_arch.h
new file mode 100644
index 00000000..ddd29578
--- /dev/null
+++ b/arch/loongarch64/syscall_arch.h
@@ -0,0 +1,137 @@
+#define __SYSCALL_LL_E(x) (x)
+#define __SYSCALL_LL_O(x) (x)
+
+#define SYSCALL_CLOBBERLIST \
+ "$t0", "$t1", "$t2", "$t3", \
+ "$t4", "$t5", "$t6", "$t7", "$t8", "memory"
+
+static inline long __syscall0(long n)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0");
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "=r"(a0)
+ : "r"(a7)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+static inline long __syscall1(long n, long a)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0") = a;
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "+r"(a0)
+ : "r"(a7)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+static inline long __syscall2(long n, long a, long b)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0") = a;
+ register long a1 __asm__("$a1") = b;
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "+r"(a0)
+ : "r"(a7), "r"(a1)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+static inline long __syscall3(long n, long a, long b, long c)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0") = a;
+ register long a1 __asm__("$a1") = b;
+ register long a2 __asm__("$a2") = c;
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "+r"(a0)
+ : "r"(a7), "r"(a1), "r"(a2)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+static inline long __syscall4(long n, long a, long b, long c, long d)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0") = a;
+ register long a1 __asm__("$a1") = b;
+ register long a2 __asm__("$a2") = c;
+ register long a3 __asm__("$a3") = d;
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "+r"(a0)
+ : "r"(a7), "r"(a1), "r"(a2), "r"(a3)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+static inline long __syscall5(long n, long a, long b, long c, long d, long e)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0") = a;
+ register long a1 __asm__("$a1") = b;
+ register long a2 __asm__("$a2") = c;
+ register long a3 __asm__("$a3") = d;
+ register long a4 __asm__("$a4") = e;
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "+r"(a0)
+ : "r"(a7), "r"(a1), "r"(a2), "r"(a3), "r"(a4)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+static inline long __syscall6(long n, long a, long b, long c, long d, long e, long f)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0") = a;
+ register long a1 __asm__("$a1") = b;
+ register long a2 __asm__("$a2") = c;
+ register long a3 __asm__("$a3") = d;
+ register long a4 __asm__("$a4") = e;
+ register long a5 __asm__("$a5") = f;
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "+r"(a0)
+ : "r"(a7), "r"(a1), "r"(a2), "r"(a3), "r"(a4), "r"(a5)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+static inline long __syscall7(long n, long a, long b, long c, long d, long e, long f, long g)
+{
+ register long a7 __asm__("$a7") = n;
+ register long a0 __asm__("$a0") = a;
+ register long a1 __asm__("$a1") = b;
+ register long a2 __asm__("$a2") = c;
+ register long a3 __asm__("$a3") = d;
+ register long a4 __asm__("$a4") = e;
+ register long a5 __asm__("$a5") = f;
+ register long a6 __asm__("$a6") = g;
+
+ __asm__ __volatile__ (
+ "syscall 0"
+ : "+r"(a0)
+ : "r"(a7), "r"(a1), "r"(a2), "r"(a3), "r"(a4), "r"(a5), "r"(a6)
+ : SYSCALL_CLOBBERLIST);
+ return a0;
+}
+
+#define VDSO_USEFUL
+#define VDSO_CGT_SYM "__vdso_clock_gettime"
+#define VDSO_CGT_VER "LINUX_2.6"
+
+#define IPC_64 0
diff --git a/configure b/configure
index ca5cbc0b..72f4969c 100755
--- a/configure
+++ b/configure
@@ -338,6 +338,7 @@ powerpc*|ppc*) ARCH=powerpc ;;
riscv64*) ARCH=riscv64 ;;
sh[1-9bel-]*|sh|superh*) ARCH=sh ;;
s390x*) ARCH=s390x ;;
+loongarch64*) ARCH=loongarch64 ;;
unknown) fail "$0: unable to detect target arch; try $0 --target=..." ;;
*) fail "$0: unknown or unsupported target \"$target\"" ;;
esac
diff --git a/crt/loongarch64/crti.s b/crt/loongarch64/crti.s
new file mode 100644
index 00000000..96a754d3
--- /dev/null
+++ b/crt/loongarch64/crti.s
@@ -0,0 +1,15 @@
+.section .init
+.global _init
+_init:
+ addi.d $r3,$r3,-16
+ st.d $fp,$r3,0
+ st.d $ra,$r3,8
+ addi.d $fp,$r3,16
+
+.section .fini
+.global _fini
+_fini:
+ addi.d $r3,$r3,-16
+ st.d $fp,$r3,0
+ st.d $ra,$r3,8
+ addi.d $fp,$r3,16
diff --git a/crt/loongarch64/crtn.s b/crt/loongarch64/crtn.s
new file mode 100644
index 00000000..bffb18f4
--- /dev/null
+++ b/crt/loongarch64/crtn.s
@@ -0,0 +1,12 @@
+.section .init
+ ld.d $fp,$r3,0
+ ld.d $ra,$r3,8
+ addi.d $r3,$r3,16
+ jirl $r0,$ra,0
+
+
+.section .fini
+ ld.d $fp,$r3,0
+ ld.d $ra,$r3,8
+ addi.d $r3,$r3,16
+ jirl $r0,$ra,0
diff --git a/include/elf.h b/include/elf.h
index 5170f3e2..301fc56b 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -696,6 +696,11 @@ typedef struct {
#define NT_MIPS_FP_MODE 0x801
#define NT_MIPS_MSA 0x802
#define NT_VERSION 1
+#define NT_LOONGARCH_CPUCFG 0xa00
+#define NT_LOONGARCH_CSR 0xa01
+#define NT_LOONGARCH_LSX 0xa02
+#define NT_LOONGARCH_LASX 0xa03
+#define NT_LOONGARCH_LBT 0xa04
@@ -3287,6 +3292,67 @@ enum
#define R_RISCV_SET32 56
#define R_RISCV_32_PCREL 57
+/* LoongISA ELF Flags */
+#define EM_LOONGARCH 258
+
+#define EF_LARCH_ABI 0x0003
+#define EF_LARCH_ABI_LP64 0x0003
+#define EF_LARCH_ABI_LP32 0x0001
+
+/* Loongarch specific dynamic relocations. */
+#define R_LARCH_NONE 0
+#define R_LARCH_32 1
+#define R_LARCH_64 2
+#define R_LARCH_RELATIVE 3
+#define R_LARCH_COPY 4
+#define R_LARCH_JUMP_SLOT 5
+#define R_LARCH_TLS_DTPMOD32 6
+#define R_LARCH_TLS_DTPMOD64 7
+#define R_LARCH_TLS_DTPREL32 8
+#define R_LARCH_TLS_DTPREL64 9
+#define R_LARCH_TLS_TPREL32 10
+#define R_LARCH_TLS_TPREL64 11
+#define R_LARCH_IRELATIVE 12
+#define R_LARCH_MARK_LA 20
+#define R_LARCH_MARK_PCREL 21
+#define R_LARCH_SOP_PUSH_PCREL 22
+#define R_LARCH_SOP_PUSH_ABSOLUTE 23
+#define R_LARCH_SOP_PUSH_DUP 24
+#define R_LARCH_SOP_PUSH_GPREL 25
+#define R_LARCH_SOP_PUSH_TLS_TPREL 26
+#define R_LARCH_SOP_PUSH_TLS_GOT 27
+#define R_LARCH_SOP_PUSH_TLS_GD 28
+#define R_LARCH_SOP_PUSH_PLT_PCREL 29
+#define R_LARCH_SOP_ASSERT 30
+#define R_LARCH_SOP_NOT 31
+#define R_LARCH_SOP_SUB 32
+#define R_LARCH_SOP_SL 33
+#define R_LARCH_SOP_SR 34
+#define R_LARCH_SOP_ADD 35
+#define R_LARCH_SOP_AND 36
+#define R_LARCH_SOP_IF_ELSE 37
+#define R_LARCH_SOP_POP_32_S_10_5 38
+#define R_LARCH_SOP_POP_32_U_10_12 39
+#define R_LARCH_SOP_POP_32_S_10_12 40
+#define R_LARCH_SOP_POP_32_S_10_16 41
+#define R_LARCH_SOP_POP_32_S_10_16_S2 42
+#define R_LARCH_SOP_POP_32_S_5_20 43
+#define R_LARCH_SOP_POP_32_S_0_5_10_16_S2 44
+#define R_LARCH_SOP_POP_32_S_0_10_10_16_S2 45
+#define R_LARCH_SOP_POP_32_U 46
+#define R_LARCH_ADD8 47
+#define R_LARCH_ADD16 48
+#define R_LARCH_ADD24 49
+#define R_LARCH_ADD32 50
+#define R_LARCH_ADD64 51
+#define R_LARCH_SUB8 52
+#define R_LARCH_SUB16 53
+#define R_LARCH_SUB24 54
+#define R_LARCH_SUB32 55
+#define R_LARCH_SUB64 56
+#define R_LARCH_GNU_VTINHERIT 57
+#define R_LARCH_GNU_VTENTRY 58
+
#ifdef __cplusplus
}
#endif
diff --git a/src/fenv/loongarch64/fenv.S b/src/fenv/loongarch64/fenv.S
new file mode 100644
index 00000000..049234be
--- /dev/null
+++ b/src/fenv/loongarch64/fenv.S
@@ -0,0 +1,72 @@
+#ifndef __loongarch_soft_float
+
+.global feclearexcept
+.type feclearexcept,@function
+feclearexcept:
+ li.w $a1, 0x1f0000 //flags in 16-20 bit of fcsr0.
+ and $a0, $a0, $a1
+ movfcsr2gr $a1, $r0
+ or $a1, $a1, $a0
+ xor $a1, $a1, $a0
+ movgr2fcsr $r0, $a1
+ li.w $v0, 0
+ jirl $zero, $ra, 0
+
+.global feraiseexcept
+.type feraiseexcept,@function
+feraiseexcept:
+ li.w $a1, 0x1f0000
+ and $a0, $a0, $a1
+ movfcsr2gr $a1, $r0
+ or $a1, $a1, $a0
+ movgr2fcsr $r0, $a1
+ li.w $v0, 0
+ jirl $zero, $ra, 0
+
+.global fetestexcept
+.type fetestexcept,@function
+fetestexcept:
+ li.w $a1, 0x1f0000
+ and $a0, $a0, $a1
+ movfcsr2gr $a1, $r0
+ and $v0, $a1, $a0
+ jirl $zero, $ra, 0
+
+.global fegetround
+.type fegetround,@function
+fegetround:
+ movfcsr2gr $v0, $r0
+ andi $v0, $v0, 0x300 //fcsr0.RM
+ jirl $zero, $ra, 0
+
+.global __fesetround
+.hidden __fesetround
+.type __fesetround,@function
+__fesetround:
+ movfcsr2gr $a1, $r0
+ li.w $a2, -769 //0xfffffcff
+ and $a1, $a1, $a2
+ or $a1, $a1, $a0
+ movgr2fcsr $r0, $a1
+ li.w $v0, 0
+ jirl $zero, $ra, 0
+
+.global fegetenv
+.type fegetenv,@function
+fegetenv:
+ movfcsr2gr $a1, $r0
+ st.w $a1, $a0, 0
+ li.w $v0, 0
+ jirl $zero, $ra, 0
+
+.global fesetenv
+.type fesetenv,@function
+fesetenv:
+ addi.d $a1, $a0, 1
+ beq $a1, $r0, 1f
+ ld.w $a1, $a0, 0
+1: movgr2fcsr $r0, $a1
+ li.w $v0, 0
+ jirl $zero, $ra, 0
+
+#endif
diff --git a/src/ldso/loongarch64/dlsym.s b/src/ldso/loongarch64/dlsym.s
new file mode 100644
index 00000000..10ac5c7f
--- /dev/null
+++ b/src/ldso/loongarch64/dlsym.s
@@ -0,0 +1,12 @@
+.global dlsym
+.hidden __dlsym
+.type dlsym,@function
+dlsym:
+ move $a2, $ra
+ la.global $r16, __dlsym
+ addi.d $sp, $sp, -8
+ st.d $ra, $sp, 0
+ jirl $ra, $r16, 0
+ ld.d $ra, $sp, 0
+ addi.d $sp, $sp, 8
+ jirl $r0, $ra, 0
diff --git a/src/setjmp/loongarch64/longjmp.S b/src/setjmp/loongarch64/longjmp.S
new file mode 100644
index 00000000..41d897ed
--- /dev/null
+++ b/src/setjmp/loongarch64/longjmp.S
@@ -0,0 +1,37 @@
+.global _longjmp
+.global longjmp
+.type _longjmp,@function
+.type longjmp,@function
+_longjmp:
+longjmp:
+ add.d $t5, $a0, $zero
+ add.d $v0, $a1, $zero
+
+ bne $v0, $zero, 1f
+ addi.d $v0, $v0, 1
+
+1:
+ ld.d $ra, $t5, 0
+ ld.d $sp, $t5, 8
+ ld.d $r21,$t5, 16
+ ld.d $fp, $t5, 24
+ ld.d $s0, $t5, 32
+ ld.d $s1, $t5, 40
+ ld.d $s2, $t5, 48
+ ld.d $s3, $t5, 56
+ ld.d $s4, $t5, 64
+ ld.d $s5, $t5, 72
+ ld.d $s6, $t5, 80
+ ld.d $s7, $t5, 88
+ ld.d $s8, $t5, 96
+#ifndef __loongarch64_soft_float
+ fld.d $fs0, $t5, 104
+ fld.d $fs1, $t5, 112
+ fld.d $fs2, $t5, 120
+ fld.d $fs3, $t5, 128
+ fld.d $fs4, $t5, 136
+ fld.d $fs5, $t5, 144
+ fld.d $fs6, $t5, 152
+ fld.d $fs7, $t5, 160
+#endif
+ jirl $zero, $ra, 0
diff --git a/src/setjmp/loongarch64/setjmp.S b/src/setjmp/loongarch64/setjmp.S
new file mode 100644
index 00000000..8dca3cb8
--- /dev/null
+++ b/src/setjmp/loongarch64/setjmp.S
@@ -0,0 +1,34 @@
+.global __setjmp
+.global _setjmp
+.global setjmp
+.type __setjmp,@function
+.type _setjmp,@function
+.type setjmp,@function
+__setjmp:
+_setjmp:
+setjmp:
+ st.d $ra, $a0, 0
+ st.d $sp, $a0, 8
+ st.d $r21,$a0, 16
+ st.d $fp, $a0, 24
+ st.d $s0, $a0, 32
+ st.d $s1, $a0, 40
+ st.d $s2, $a0, 48
+ st.d $s3, $a0, 56
+ st.d $s4, $a0, 64
+ st.d $s5, $a0, 72
+ st.d $s6, $a0, 80
+ st.d $s7, $a0, 88
+ st.d $s8, $a0, 96
+#ifndef __loongarch64_soft_float
+ fst.d $fs0, $a0, 104
+ fst.d $fs1, $a0, 112
+ fst.d $fs2, $a0, 120
+ fst.d $fs3, $a0, 128
+ fst.d $fs4, $a0, 136
+ fst.d $fs5, $a0, 144
+ fst.d $fs6, $a0, 152
+ fst.d $fs7, $a0, 160
+#endif
+ xor $v0, $v0, $v0
+ jirl $zero, $ra, 0
diff --git a/src/signal/loongarch64/restore.s b/src/signal/loongarch64/restore.s
new file mode 100644
index 00000000..9bf015a0
--- /dev/null
+++ b/src/signal/loongarch64/restore.s
@@ -0,0 +1,10 @@
+.global __restore_rt
+.global __restore
+.hidden __restore_rt
+.hidden __restore
+.type __restore_rt,@function
+.type __restore,@function
+__restore_rt:
+__restore:
+ ori $a7, $zero, 139
+ syscall 0
diff --git a/src/signal/loongarch64/sigsetjmp.s b/src/signal/loongarch64/sigsetjmp.s
new file mode 100644
index 00000000..d53f334a
--- /dev/null
+++ b/src/signal/loongarch64/sigsetjmp.s
@@ -0,0 +1,29 @@
+.global sigsetjmp
+.global __sigsetjmp
+.type sigsetjmp,@function
+.type __sigsetjmp,@function
+sigsetjmp:
+__sigsetjmp:
+ or $t5, $a0, $zero
+ or $t6, $a1, $zero
+
+ # comparing save mask with 0, if equals to 0 then
+ # sigsetjmp is equal to setjmp.
+ beq $t6, $zero, 1f
+ st.d $ra, $t5, 168
+
+ # save base of got so that we can use it later
+ # once we return from 'longjmp'
+ la.global $t8, setjmp
+ jirl $ra, $t8, 0
+
+ or $v1, $v0, $zero # Return from 'setjmp' or 'longjmp'
+ ld.d $ra, $t5, 168 # Restore ra of sigsetjmp
+ or $a0, $t5, $zero
+
+.hidden __sigsetjmp_tail
+ la.global $t8, __sigsetjmp_tail
+ jirl $zero, $t8, 0
+1:
+ la.global $t8, setjmp
+ jirl $zero, $t8, 0
diff --git a/src/thread/loongarch64/__set_thread_area.s b/src/thread/loongarch64/__set_thread_area.s
new file mode 100644
index 00000000..421cd381
--- /dev/null
+++ b/src/thread/loongarch64/__set_thread_area.s
@@ -0,0 +1,7 @@
+.global __set_thread_area
+.hidden __set_thread_area
+.type __set_thread_area,@function
+__set_thread_area:
+ or $tp, $a0, $zero
+ ori $a0, $zero, 0
+ jirl $zero, $ra, 0
diff --git a/src/thread/loongarch64/__unmapself.s b/src/thread/loongarch64/__unmapself.s
new file mode 100644
index 00000000..b77e6d1d
--- /dev/null
+++ b/src/thread/loongarch64/__unmapself.s
@@ -0,0 +1,7 @@
+.global __unmapself
+.type __unmapself, @function
+__unmapself:
+ li.d $a7, 215
+ syscall 0 # call munmap
+ li.d $a7, 93
+ syscall 0 # call exit
diff --git a/src/thread/loongarch64/clone.s b/src/thread/loongarch64/clone.s
new file mode 100644
index 00000000..a1ac988c
--- /dev/null
+++ b/src/thread/loongarch64/clone.s
@@ -0,0 +1,28 @@
+#__clone(func, stack, flags, arg, ptid, tls, ctid)
+# a0, a1, a2, a3, a4, a5, a6
+# sys_clone(flags, stack, ptid, ctid, tls)
+# a0, a1, a2, a3, a4
+
+.global __clone
+.hidden __clone
+.type __clone,@function
+__clone:
+ # Save function pointer and argument pointer on new thread stack
+ addi.d $a1, $a1, -16
+ st.d $a0, $a1, 0 # save function pointer
+ st.d $a3, $a1, 8 # save argument pointer
+ or $a0, $a2, $zero
+ or $a2, $a4, $zero
+ or $a3, $a6, $zero
+ or $a4, $a5, $zero
+ ori $a7, $zero, 220
+ syscall 0 # call clone
+
+ beqz $a0, 1f # whether child process
+ jirl $zero, $ra, 0 # parent process return
+1:
+ ld.d $t8, $sp, 0 # function pointer
+ ld.d $a0, $sp, 8 # argument pointer
+ jirl $ra, $t8, 0 # call the user's function
+ ori $a7, $zero, 93
+ syscall 0 # child process exit
diff --git a/src/thread/loongarch64/syscall_cp.s b/src/thread/loongarch64/syscall_cp.s
new file mode 100644
index 00000000..3903ed2c
--- /dev/null
+++ b/src/thread/loongarch64/syscall_cp.s
@@ -0,0 +1,29 @@
+.global __cp_begin
+.hidden __cp_begin
+.global __cp_end
+.hidden __cp_end
+.global __cp_cancel
+.hidden __cp_cancel
+.hidden __cancel
+.global __syscall_cp_asm
+.hidden __syscall_cp_asm
+.type __syscall_cp_asm,@function
+
+__syscall_cp_asm:
+__cp_begin:
+ ld.w $a0, $a0, 0
+ bnez $a0, __cp_cancel
+ or $t8, $a1, $zero # reserve system call number
+ or $a0, $a2, $zero
+ or $a1, $a3, $zero
+ or $a2, $a4, $zero
+ or $a3, $a5, $zero
+ or $a4, $a6, $zero
+ or $a5, $a7, $zero
+ or $a7, $t8, $zero
+ syscall 0
+__cp_end:
+ jirl $zero, $ra, 0
+__cp_cancel:
+ la.local $t8, __cancel
+ jirl $zero, $t8, 0
--
2.34.1
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 3:52 [musl] add loongarch64 port 王洪亮
@ 2022-03-22 12:59 ` Rich Felker
2022-03-22 15:06 ` Jeffrey Walton
2022-03-24 2:22 ` 王洪亮
2022-03-22 19:03 ` Rich Felker
2022-03-29 8:12 ` [musl] " 王洪亮
2 siblings, 2 replies; 52+ messages in thread
From: Rich Felker @ 2022-03-22 12:59 UTC (permalink / raw)
To: 王洪亮; +Cc: musl, liuxue, lvjianmin
On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
> Hi,
>
> Thank you for give us some useful suggestions on the first submit
>
> from 翟小娟 <zhaixiaojuan@loongson.cn>.
>
> we review code and make changes on code specification, code style
>
> and code errors.
>
>
> The new patch has been published in
>
> https://github.com/loongson/musl/tree/loongarch-v1.0.
>
>
> The linux kernel has been published in
>
> https://github.com/loongson/linux/tree/loongarch-next.
>
>
> we alse published gcc, glibc in https://github.com/loongson
>
> and submitting to the community.
>
>
> we can supply a physical machine remote login for test musl.
>
> It has been compiled and run the libc-test successfully.
>
>
> Please code review, thanks!
>
>
> Hongliang Wang
>
> >From f5df725607675b370daec09a14ad130c792fa0d2 Mon Sep 17 00:00:00 2001
> From: wanghongliang <wanghongliang@loongson.cn>
> Date: Mon, 21 Mar 2022 06:13:20 +0800
> Subject: [PATCH] add loongarch64 port.
>
> Author: xiaojuanZhai <zhaixiaojuan@loongson.cn>
> Author: meidanLi <limeidan@loongson.cn>
> Author: guoqiChen <chenguoqi@loongson.cn>
> Author: xiaolinZhao <zhaoxiaolin@loongson.cn>
> Author: Fanpeng <fanpeng@loongson.cn>
> Author: jiantaoShan <shanjiantao@loongson.cn>
> Author: xuhuiQiang <qiangxuhui@loongson.cn>
> Author: jingyunHua <huajingyun@loongson.cn>
> Author: liuxue <liuxue@loongson.cn>
> Author: wanghongliang <wanghongliang@loongson.cn>
>
> Signed-off-by: wanghongliang <wanghongliang@loongson.cn>
> ---
> arch/loongarch64/atomic_arch.h | 53 ++++
> arch/loongarch64/bits/alltypes.h.in | 20 ++
> arch/loongarch64/bits/fcntl.h | 40 +++
> arch/loongarch64/bits/fenv.h | 20 ++
> arch/loongarch64/bits/float.h | 16 ++
> arch/loongarch64/bits/hwcap.h | 14 +
> arch/loongarch64/bits/posix.h | 2 +
> arch/loongarch64/bits/ptrace.h | 4 +
> arch/loongarch64/bits/reg.h | 66 +++++
> arch/loongarch64/bits/setjmp.h | 1 +
> arch/loongarch64/bits/signal.h | 79 ++++++
> arch/loongarch64/bits/stat.h | 20 ++
> arch/loongarch64/bits/stdint.h | 20 ++
> arch/loongarch64/bits/syscall.h.in | 307 +++++++++++++++++++++
> arch/loongarch64/bits/user.h | 5 +
> arch/loongarch64/crt_arch.h | 14 +
> arch/loongarch64/kstat.h | 21 ++
> arch/loongarch64/pthread_arch.h | 13 +
> arch/loongarch64/reloc.h | 35 +++
> arch/loongarch64/syscall_arch.h | 137 +++++++++
> configure | 1 +
> crt/loongarch64/crti.s | 15 +
> crt/loongarch64/crtn.s | 12 +
> include/elf.h | 66 +++++
> src/fenv/loongarch64/fenv.S | 72 +++++
> src/ldso/loongarch64/dlsym.s | 12 +
> src/setjmp/loongarch64/longjmp.S | 37 +++
> src/setjmp/loongarch64/setjmp.S | 34 +++
> src/signal/loongarch64/restore.s | 10 +
> src/signal/loongarch64/sigsetjmp.s | 29 ++
> src/thread/loongarch64/__set_thread_area.s | 7 +
> src/thread/loongarch64/__unmapself.s | 7 +
> src/thread/loongarch64/clone.s | 28 ++
> src/thread/loongarch64/syscall_cp.s | 29 ++
> 34 files changed, 1246 insertions(+)
> create mode 100644 arch/loongarch64/atomic_arch.h
> create mode 100644 arch/loongarch64/bits/alltypes.h.in
> create mode 100644 arch/loongarch64/bits/fcntl.h
> create mode 100644 arch/loongarch64/bits/fenv.h
> create mode 100644 arch/loongarch64/bits/float.h
> create mode 100644 arch/loongarch64/bits/hwcap.h
> create mode 100644 arch/loongarch64/bits/posix.h
> create mode 100644 arch/loongarch64/bits/ptrace.h
> create mode 100644 arch/loongarch64/bits/reg.h
> create mode 100644 arch/loongarch64/bits/setjmp.h
> create mode 100644 arch/loongarch64/bits/signal.h
> create mode 100644 arch/loongarch64/bits/stat.h
> create mode 100644 arch/loongarch64/bits/stdint.h
> create mode 100644 arch/loongarch64/bits/syscall.h.in
> create mode 100644 arch/loongarch64/bits/user.h
> create mode 100644 arch/loongarch64/crt_arch.h
> create mode 100644 arch/loongarch64/kstat.h
> create mode 100644 arch/loongarch64/pthread_arch.h
> create mode 100644 arch/loongarch64/reloc.h
> create mode 100644 arch/loongarch64/syscall_arch.h
> create mode 100644 crt/loongarch64/crti.s
> create mode 100644 crt/loongarch64/crtn.s
> create mode 100644 src/fenv/loongarch64/fenv.S
> create mode 100644 src/ldso/loongarch64/dlsym.s
> create mode 100644 src/setjmp/loongarch64/longjmp.S
> create mode 100644 src/setjmp/loongarch64/setjmp.S
> create mode 100644 src/signal/loongarch64/restore.s
> create mode 100644 src/signal/loongarch64/sigsetjmp.s
> create mode 100644 src/thread/loongarch64/__set_thread_area.s
> create mode 100644 src/thread/loongarch64/__unmapself.s
> create mode 100644 src/thread/loongarch64/clone.s
> create mode 100644 src/thread/loongarch64/syscall_cp.s
>
> diff --git a/arch/loongarch64/atomic_arch.h b/arch/loongarch64/atomic_arch.h
> new file mode 100644
> index 00000000..bf4805c9
> --- /dev/null
> +++ b/arch/loongarch64/atomic_arch.h
> @@ -0,0 +1,53 @@
> +#define a_ll a_ll
> +static inline int a_ll(volatile int *p)
> +{
> + int v;
> + __asm__ __volatile__ (
> + "ll.w %0, %1"
> + : "=r"(v)
> + : "ZC"(*p));
> + return v;
> +}
> +
> +#define a_sc a_sc
> +static inline int a_sc(volatile int *p, int v)
> +{
> + int r;
> + __asm__ __volatile__ (
> + "sc.w %0, %1"
> + : "=r"(r), "=ZC"(*p)
> + : "0"(v) : "memory");
> + return r;
> +}
> +
> +#define a_ll_p a_ll_p
> +static inline void *a_ll_p(volatile void *p)
> +{
> + void *v;
> + __asm__ __volatile__ (
> + "ll.d %0, %1"
> + : "=r"(v)
> + : "ZC"(*(void *volatile *)p));
> + return v;
> +}
> +
> +#define a_sc_p a_sc_p
> +static inline int a_sc_p(volatile void *p, void *v)
> +{
> + long r;
> + __asm__ __volatile__ (
> + "sc.d %0, %1"
> + : "=r"(r), "=ZC"(*(void *volatile *)p)
> + : "0"(v)
> + : "memory");
> + return r;
> +}
> +
> +#define a_barrier a_barrier
> +static inline void a_barrier()
> +{
> + __asm__ __volatile__ ("dbar 0" : : : "memory");
> +}
> +
> +#define a_pre_llsc a_barrier
> +#define a_post_llsc a_barrier
I don't see anything wrong here standing out, but haven't reviewed the
ISA's requirements on the use of ll/sc to be sure. If anyone else has
knowledge to review this part that would be great.
> diff --git a/arch/loongarch64/bits/alltypes.h.in b/arch/loongarch64/bits/alltypes.h.in
> new file mode 100644
> index 00000000..38871b5f
> --- /dev/null
> +++ b/arch/loongarch64/bits/alltypes.h.in
> @@ -0,0 +1,20 @@
> +#define _Addr long
> +#define _Int64 long
> +#define _Reg long
> +
> +#define __BYTE_ORDER 1234
> +#define __LONG_MAX 0x7fffffffffffffffL
> +
> +TYPEDEF __builtin_va_list va_list;
> +TYPEDEF __builtin_va_list __isoc_va_list;
> +
> +#ifndef __cplusplus
> +TYPEDEF int wchar_t;
> +#endif
> +
> +TYPEDEF float float_t;
> +TYPEDEF double double_t;
> +
> +TYPEDEF struct { long long __ll; long double __ld; } max_align_t;
> +
> +TYPEDEF unsigned nlink_t;
va_list and __isoc_va_list are no longer defined by the arch's
alltypes.h.in, so they can be removed. I think the rest of that is ok.
> diff --git a/arch/loongarch64/bits/fcntl.h b/arch/loongarch64/bits/fcntl.h
> new file mode 100644
> index 00000000..9bcbb7ff
> --- /dev/null
> +++ b/arch/loongarch64/bits/fcntl.h
> @@ -0,0 +1,40 @@
> +#define O_CREAT 0100
> +#define O_EXCL 0200
> +#define O_NOCTTY 0400
> +#define O_TRUNC 01000
> +#define O_APPEND 02000
> +#define O_NONBLOCK 04000
> +#define O_DSYNC 010000
> +#define O_SYNC 04010000
> +#define O_RSYNC 04010000
> +#define O_DIRECTORY 0200000
> +#define O_NOFOLLOW 0400000
> +#define O_CLOEXEC 02000000
> +
> +#define O_ASYNC 020000
> +#define O_DIRECT 040000
> +#define O_LARGEFILE 0100000
> +#define O_NOATIME 01000000
> +#define O_PATH 010000000
> +#define O_TMPFILE 020000000
> +#define O_NDELAY O_NONBLOCK
> +
> +#define F_DUPFD 0
> +#define F_GETFD 1
> +#define F_SETFD 2
> +#define F_GETFL 3
> +#define F_SETFL 4
> +
> +#define F_SETOWN 8
> +#define F_GETOWN 9
> +#define F_SETSIG 10
> +#define F_GETSIG 11
> +
> +#define F_GETLK 5
> +#define F_SETLK 6
> +#define F_SETLKW 7
> +
> +#define F_SETOWN_EX 15
> +#define F_GETOWN_EX 16
> +
> +#define F_GETOWNER_UIDS 17
AFAICT this file is identical to the generic one (with 32/64 bit #if
evaluated already) so it can and should be dropped.
> +++ b/arch/loongarch64/bits/signal.h
> @@ -0,0 +1,79 @@
> +#if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
> + || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> +
> +#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> +#define MINSIGSTKSZ 4096
> +#define SIGSTKSZ 16384
> +#endif
> +
> +typedef unsigned long greg_t, gregset_t[32];
> +
> +typedef struct sigcontext {
> + unsigned long pc;
> + gregset_t gregs;
> + unsigned int flags;
> + unsigned long extcontext[0] __attribute__((__aligned__(16)));
> +}mcontext_t;
[0] is not valid, and having a flexible array member here is possibly
not even useful since I don't think it would be valid to access it via
uc->uc_mcontext.extcontext[] since the instance of mcontext_t inside
the ucontext struct does not have FAM space belonging to it, even if
additional space was allocated past the end of the ucontext_t. In
other words, I think compilers would be justified in treating attempts
to access it this way as UB and optimizing them out.
> diff --git a/arch/loongarch64/bits/stat.h b/arch/loongarch64/bits/stat.h
> new file mode 100644
> index 00000000..b620e142
> --- /dev/null
> +++ b/arch/loongarch64/bits/stat.h
> @@ -0,0 +1,20 @@
> +struct stat {
> + dev_t st_dev;
> + int __pad1[3];
> + ino_t st_ino;
> + mode_t st_mode;
> + nlink_t st_nlink;
> + uid_t st_uid;
> + gid_t st_gid;
> + dev_t st_rdev;
> + unsigned int __pad2[2];
> + off_t st_size;
> + int __pad3;
> + struct timespec st_atim;
> + struct timespec st_mtim;
> + struct timespec st_ctim;
> + blksize_t st_blksize;
> + unsigned int __pad4;
> + blkcnt_t st_blocks;
> + int __pad5[14];
> +};
__pad1[3] looks wrong -- st_ino will be aligned on a 64-bit boundary
so there can't be an odd number of 32-bit ints before it. Naturally,
it will be aligned with additional padding, but the intent here was
probably to make all the padding explicit. Moreover, this isn't
reflecting a kernel structure, just a userspace type that musl gets to
define, so I'm not sure why it's being defined for a new arch with
lots of gratuitous padding rather than just using a generic
definition. I guess it was just copied from the mips64 one (which also
has these problems).
If you're already using this in production and don't want to break
ABI, I don't see any real need to change it though. It doesn't really
matter. Making it __pad1[4] would still be a good idea (and we should
fix that on mips64) -- that doesn't break ABI.
> diff --git a/arch/loongarch64/pthread_arch.h b/arch/loongarch64/pthread_arch.h
> new file mode 100644
> index 00000000..27f50e4c
> --- /dev/null
> +++ b/arch/loongarch64/pthread_arch.h
> @@ -0,0 +1,13 @@
> +static inline uintptr_t __get_tp()
> +{
> + uintptr_t tp;
> + __asm__ ("or %0, $tp, $zero" : "=r" (tp) );
> + return tp;
> +}
> +
> +#define TLS_ABOVE_TP
> +#define GAP_ABOVE_TP 0
> +
> +#define DTP_OFFSET 0
> +
> +#define MC_PC pc
This can be done as something like:
static inline uintptr_t __get_tp()
{
register uintptr_t tp __asm__("tp");
__asm__ ("" : "=r" (tp) );
return tp;
}
if the compiler doesn't botch it. Historically clang had trouble with
that, so if that's the case, just stick with what you had -- it's not
too costly doing a gratuitous move.
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 12:59 ` Rich Felker
@ 2022-03-22 15:06 ` Jeffrey Walton
2022-03-22 16:04 ` Rich Felker
2022-03-24 2:22 ` 王洪亮
1 sibling, 1 reply; 52+ messages in thread
From: Jeffrey Walton @ 2022-03-22 15:06 UTC (permalink / raw)
To: musl; +Cc: 王洪亮, liuxue, lvjianmin
On Tue, Mar 22, 2022 at 8:59 AM Rich Felker <dalias@libc.org> wrote:
> On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
...
> > +++ b/arch/loongarch64/bits/signal.h
> > @@ -0,0 +1,79 @@
> > +#if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
> > + || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> > +
> > +#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> > +#define MINSIGSTKSZ 4096
> > +#define SIGSTKSZ 16384
> > +#endif
> > +
> > +typedef unsigned long greg_t, gregset_t[32];
> > +
> > +typedef struct sigcontext {
> > + unsigned long pc;
> > + gregset_t gregs;
> > + unsigned int flags;
> > + unsigned long extcontext[0] __attribute__((__aligned__(16)));
> > +}mcontext_t;
>
> [0] is not valid, and having a flexible array member here is possibly
> not even useful since I don't think it would be valid to access it via
> uc->uc_mcontext.extcontext[] since the instance of mcontext_t inside
> the ucontext struct does not have FAM space belonging to it, even if
> additional space was allocated past the end of the ucontext_t. In
> other words, I think compilers would be justified in treating attempts
> to access it this way as UB and optimizing them out.
I believe zero-length arrays are legal in C99. I'm not sure how well
it applies here or to Musl on some (older?) platforms.
Microsoft used to use [1] for ANYSIZE_ARRAY. Also see
https://web.archive.org/web/20120209061713/http://blogs.msdn.com/b/oldnewthing/archive/2004/08/26/220873.aspx
Jeff
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 15:06 ` Jeffrey Walton
@ 2022-03-22 16:04 ` Rich Felker
2022-03-24 3:01 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-03-22 16:04 UTC (permalink / raw)
To: Jeffrey Walton; +Cc: musl
On Tue, Mar 22, 2022 at 11:06:41AM -0400, Jeffrey Walton wrote:
> On Tue, Mar 22, 2022 at 8:59 AM Rich Felker <dalias@libc.org> wrote:
> > On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
> ....
> > > +++ b/arch/loongarch64/bits/signal.h
> > > @@ -0,0 +1,79 @@
> > > +#if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
> > > + || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> > > +
> > > +#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> > > +#define MINSIGSTKSZ 4096
> > > +#define SIGSTKSZ 16384
> > > +#endif
> > > +
> > > +typedef unsigned long greg_t, gregset_t[32];
> > > +
> > > +typedef struct sigcontext {
> > > + unsigned long pc;
> > > + gregset_t gregs;
> > > + unsigned int flags;
> > > + unsigned long extcontext[0] __attribute__((__aligned__(16)));
> > > +}mcontext_t;
> >
> > [0] is not valid, and having a flexible array member here is possibly
> > not even useful since I don't think it would be valid to access it via
> > uc->uc_mcontext.extcontext[] since the instance of mcontext_t inside
> > the ucontext struct does not have FAM space belonging to it, even if
> > additional space was allocated past the end of the ucontext_t. In
> > other words, I think compilers would be justified in treating attempts
> > to access it this way as UB and optimizing them out.
>
> I believe zero-length arrays are legal in C99. I'm not sure how well
> it applies here or to Musl on some (older?) platforms.
No, those are flexible array members and are declared with [] not [0].
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 16:04 ` Rich Felker
@ 2022-03-24 3:01 ` 王洪亮
0 siblings, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-03-24 3:01 UTC (permalink / raw)
To: musl
Hi,
the zero-length array in sigcontext is used for context extend.
this applycation has some advantage:
1.the zero-length array not take up space of struct sigcontext
2.the extended context is continuous with sigcontext.
Hongliang Wang
在 2022/3/23 上午12:04, Rich Felker 写道:
> On Tue, Mar 22, 2022 at 11:06:41AM -0400, Jeffrey Walton wrote:
>> On Tue, Mar 22, 2022 at 8:59 AM Rich Felker <dalias@libc.org> wrote:
>>> On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
>> ....
>>>> +++ b/arch/loongarch64/bits/signal.h
>>>> @@ -0,0 +1,79 @@
>>>> +#if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
>>>> + || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
>>>> +
>>>> +#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
>>>> +#define MINSIGSTKSZ 4096
>>>> +#define SIGSTKSZ 16384
>>>> +#endif
>>>> +
>>>> +typedef unsigned long greg_t, gregset_t[32];
>>>> +
>>>> +typedef struct sigcontext {
>>>> + unsigned long pc;
>>>> + gregset_t gregs;
>>>> + unsigned int flags;
>>>> + unsigned long extcontext[0] __attribute__((__aligned__(16)));
>>>> +}mcontext_t;
>>> [0] is not valid, and having a flexible array member here is possibly
>>> not even useful since I don't think it would be valid to access it via
>>> uc->uc_mcontext.extcontext[] since the instance of mcontext_t inside
>>> the ucontext struct does not have FAM space belonging to it, even if
>>> additional space was allocated past the end of the ucontext_t. In
>>> other words, I think compilers would be justified in treating attempts
>>> to access it this way as UB and optimizing them out.
>> I believe zero-length arrays are legal in C99. I'm not sure how well
>> it applies here or to Musl on some (older?) platforms.
> No, those are flexible array members and are declared with [] not [0].
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 12:59 ` Rich Felker
2022-03-22 15:06 ` Jeffrey Walton
@ 2022-03-24 2:22 ` 王洪亮
1 sibling, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-03-24 2:22 UTC (permalink / raw)
To: musl
Hi,
I fixed these problems pointed out.
1. delete va_list and __isoc_va_list in arch's alltypes.h.in,
add blksize_t for struct stat and struct kstat.
diff --git a/arch/loongarch64/bits/alltypes.h.in
b/arch/loongarch64/bits/alltypes.h.in
index 38871b5f..7c02c63c 100644
--- a/arch/loongarch64/bits/alltypes.h.in
+++ b/arch/loongarch64/bits/alltypes.h.in
@@ -5,9 +5,6 @@
#define __BYTE_ORDER 1234
#define __LONG_MAX 0x7fffffffffffffffL
-TYPEDEF __builtin_va_list va_list;
-TYPEDEF __builtin_va_list __isoc_va_list;
-
#ifndef __cplusplus
TYPEDEF int wchar_t;
#endif
@@ -16,5 +13,5 @@ TYPEDEF float float_t;
TYPEDEF double double_t;
TYPEDEF struct { long long __ll; long double __ld; } max_align_t;
-
TYPEDEF unsigned nlink_t;
+TYPEDEF int blksize_t;
2. remove arch/loongarch64/bits/fcntl.h
3. adjust struct stat and kstat, keep consistent with kernel in
include/uapi/asm-generic/stat.h
diff --git a/arch/loongarch64/bits/stat.h b/arch/loongarch64/bits/stat.h
index b620e142..b7f4221b 100644
--- a/arch/loongarch64/bits/stat.h
+++ b/arch/loongarch64/bits/stat.h
@@ -1,20 +1,18 @@
struct stat {
dev_t st_dev;
- int __pad1[3];
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
- unsigned int __pad2[2];
+ unsigned long __pad;
off_t st_size;
- int __pad3;
+ blksize_t st_blksize;
+ int __pad2;
+ blkcnt_t st_blocks;
struct timespec st_atim;
struct timespec st_mtim;
struct timespec st_ctim;
- blksize_t st_blksize;
- unsigned int __pad4;
- blkcnt_t st_blocks;
- int __pad5[14];
+ unsigned __unused[2];
};
diff --git a/arch/loongarch64/kstat.h b/arch/loongarch64/kstat.h
index 4e39ffac..900f119d 100644
--- a/arch/loongarch64/kstat.h
+++ b/arch/loongarch64/kstat.h
@@ -6,9 +6,9 @@ struct kstat {
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
- unsigned long __pad1;
+ unsigned long __pad;
off_t st_size;
- unsigned st_blksize;
+ blksize_t st_blksize;
int __pad2;
blkcnt_t st_blocks;
long st_atime_sec;
4. optimize the __get_tp() implement. I already confirmed with
gcc and clang team, this optimize is ok.
diff --git a/arch/loongarch64/pthread_arch.h
b/arch/loongarch64/pthread_arch.h
index 27f50e4c..95ee4c7a 100644
--- a/arch/loongarch64/pthread_arch.h
+++ b/arch/loongarch64/pthread_arch.h
@@ -1,7 +1,7 @@
static inline uintptr_t __get_tp()
{
- uintptr_t tp;
- __asm__ ("or %0, $tp, $zero" : "=r" (tp) );
+ register uintptr_t tp __asm__("tp");
+ __asm__ ("" : "=r" (tp) );
return tp;
}
Hongliang Wang
在 2022/3/22 下午8:59, Rich Felker 写道:
> On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
>> Hi,
>>
>> Thank you for give us some useful suggestions on the first submit
>>
>> from 翟小娟 <zhaixiaojuan@loongson.cn>.
>>
>> we review code and make changes on code specification, code style
>>
>> and code errors.
>>
>>
>> The new patch has been published in
>>
>> https://github.com/loongson/musl/tree/loongarch-v1.0.
>>
>>
>> The linux kernel has been published in
>>
>> https://github.com/loongson/linux/tree/loongarch-next.
>>
>>
>> we alse published gcc, glibc in https://github.com/loongson
>>
>> and submitting to the community.
>>
>>
>> we can supply a physical machine remote login for test musl.
>>
>> It has been compiled and run the libc-test successfully.
>>
>>
>> Please code review, thanks!
>>
>>
>> Hongliang Wang
>>
>> >From f5df725607675b370daec09a14ad130c792fa0d2 Mon Sep 17 00:00:00 2001
>> From: wanghongliang <wanghongliang@loongson.cn>
>> Date: Mon, 21 Mar 2022 06:13:20 +0800
>> Subject: [PATCH] add loongarch64 port.
>>
>> Author: xiaojuanZhai <zhaixiaojuan@loongson.cn>
>> Author: meidanLi <limeidan@loongson.cn>
>> Author: guoqiChen <chenguoqi@loongson.cn>
>> Author: xiaolinZhao <zhaoxiaolin@loongson.cn>
>> Author: Fanpeng <fanpeng@loongson.cn>
>> Author: jiantaoShan <shanjiantao@loongson.cn>
>> Author: xuhuiQiang <qiangxuhui@loongson.cn>
>> Author: jingyunHua <huajingyun@loongson.cn>
>> Author: liuxue <liuxue@loongson.cn>
>> Author: wanghongliang <wanghongliang@loongson.cn>
>>
>> Signed-off-by: wanghongliang <wanghongliang@loongson.cn>
>> ---
>> arch/loongarch64/atomic_arch.h | 53 ++++
>> arch/loongarch64/bits/alltypes.h.in | 20 ++
>> arch/loongarch64/bits/fcntl.h | 40 +++
>> arch/loongarch64/bits/fenv.h | 20 ++
>> arch/loongarch64/bits/float.h | 16 ++
>> arch/loongarch64/bits/hwcap.h | 14 +
>> arch/loongarch64/bits/posix.h | 2 +
>> arch/loongarch64/bits/ptrace.h | 4 +
>> arch/loongarch64/bits/reg.h | 66 +++++
>> arch/loongarch64/bits/setjmp.h | 1 +
>> arch/loongarch64/bits/signal.h | 79 ++++++
>> arch/loongarch64/bits/stat.h | 20 ++
>> arch/loongarch64/bits/stdint.h | 20 ++
>> arch/loongarch64/bits/syscall.h.in | 307 +++++++++++++++++++++
>> arch/loongarch64/bits/user.h | 5 +
>> arch/loongarch64/crt_arch.h | 14 +
>> arch/loongarch64/kstat.h | 21 ++
>> arch/loongarch64/pthread_arch.h | 13 +
>> arch/loongarch64/reloc.h | 35 +++
>> arch/loongarch64/syscall_arch.h | 137 +++++++++
>> configure | 1 +
>> crt/loongarch64/crti.s | 15 +
>> crt/loongarch64/crtn.s | 12 +
>> include/elf.h | 66 +++++
>> src/fenv/loongarch64/fenv.S | 72 +++++
>> src/ldso/loongarch64/dlsym.s | 12 +
>> src/setjmp/loongarch64/longjmp.S | 37 +++
>> src/setjmp/loongarch64/setjmp.S | 34 +++
>> src/signal/loongarch64/restore.s | 10 +
>> src/signal/loongarch64/sigsetjmp.s | 29 ++
>> src/thread/loongarch64/__set_thread_area.s | 7 +
>> src/thread/loongarch64/__unmapself.s | 7 +
>> src/thread/loongarch64/clone.s | 28 ++
>> src/thread/loongarch64/syscall_cp.s | 29 ++
>> 34 files changed, 1246 insertions(+)
>> create mode 100644 arch/loongarch64/atomic_arch.h
>> create mode 100644 arch/loongarch64/bits/alltypes.h.in
>> create mode 100644 arch/loongarch64/bits/fcntl.h
>> create mode 100644 arch/loongarch64/bits/fenv.h
>> create mode 100644 arch/loongarch64/bits/float.h
>> create mode 100644 arch/loongarch64/bits/hwcap.h
>> create mode 100644 arch/loongarch64/bits/posix.h
>> create mode 100644 arch/loongarch64/bits/ptrace.h
>> create mode 100644 arch/loongarch64/bits/reg.h
>> create mode 100644 arch/loongarch64/bits/setjmp.h
>> create mode 100644 arch/loongarch64/bits/signal.h
>> create mode 100644 arch/loongarch64/bits/stat.h
>> create mode 100644 arch/loongarch64/bits/stdint.h
>> create mode 100644 arch/loongarch64/bits/syscall.h.in
>> create mode 100644 arch/loongarch64/bits/user.h
>> create mode 100644 arch/loongarch64/crt_arch.h
>> create mode 100644 arch/loongarch64/kstat.h
>> create mode 100644 arch/loongarch64/pthread_arch.h
>> create mode 100644 arch/loongarch64/reloc.h
>> create mode 100644 arch/loongarch64/syscall_arch.h
>> create mode 100644 crt/loongarch64/crti.s
>> create mode 100644 crt/loongarch64/crtn.s
>> create mode 100644 src/fenv/loongarch64/fenv.S
>> create mode 100644 src/ldso/loongarch64/dlsym.s
>> create mode 100644 src/setjmp/loongarch64/longjmp.S
>> create mode 100644 src/setjmp/loongarch64/setjmp.S
>> create mode 100644 src/signal/loongarch64/restore.s
>> create mode 100644 src/signal/loongarch64/sigsetjmp.s
>> create mode 100644 src/thread/loongarch64/__set_thread_area.s
>> create mode 100644 src/thread/loongarch64/__unmapself.s
>> create mode 100644 src/thread/loongarch64/clone.s
>> create mode 100644 src/thread/loongarch64/syscall_cp.s
>>
>> diff --git a/arch/loongarch64/atomic_arch.h b/arch/loongarch64/atomic_arch.h
>> new file mode 100644
>> index 00000000..bf4805c9
>> --- /dev/null
>> +++ b/arch/loongarch64/atomic_arch.h
>> @@ -0,0 +1,53 @@
>> +#define a_ll a_ll
>> +static inline int a_ll(volatile int *p)
>> +{
>> + int v;
>> + __asm__ __volatile__ (
>> + "ll.w %0, %1"
>> + : "=r"(v)
>> + : "ZC"(*p));
>> + return v;
>> +}
>> +
>> +#define a_sc a_sc
>> +static inline int a_sc(volatile int *p, int v)
>> +{
>> + int r;
>> + __asm__ __volatile__ (
>> + "sc.w %0, %1"
>> + : "=r"(r), "=ZC"(*p)
>> + : "0"(v) : "memory");
>> + return r;
>> +}
>> +
>> +#define a_ll_p a_ll_p
>> +static inline void *a_ll_p(volatile void *p)
>> +{
>> + void *v;
>> + __asm__ __volatile__ (
>> + "ll.d %0, %1"
>> + : "=r"(v)
>> + : "ZC"(*(void *volatile *)p));
>> + return v;
>> +}
>> +
>> +#define a_sc_p a_sc_p
>> +static inline int a_sc_p(volatile void *p, void *v)
>> +{
>> + long r;
>> + __asm__ __volatile__ (
>> + "sc.d %0, %1"
>> + : "=r"(r), "=ZC"(*(void *volatile *)p)
>> + : "0"(v)
>> + : "memory");
>> + return r;
>> +}
>> +
>> +#define a_barrier a_barrier
>> +static inline void a_barrier()
>> +{
>> + __asm__ __volatile__ ("dbar 0" : : : "memory");
>> +}
>> +
>> +#define a_pre_llsc a_barrier
>> +#define a_post_llsc a_barrier
> I don't see anything wrong here standing out, but haven't reviewed the
> ISA's requirements on the use of ll/sc to be sure. If anyone else has
> knowledge to review this part that would be great.
>
>> diff --git a/arch/loongarch64/bits/alltypes.h.in b/arch/loongarch64/bits/alltypes.h.in
>> new file mode 100644
>> index 00000000..38871b5f
>> --- /dev/null
>> +++ b/arch/loongarch64/bits/alltypes.h.in
>> @@ -0,0 +1,20 @@
>> +#define _Addr long
>> +#define _Int64 long
>> +#define _Reg long
>> +
>> +#define __BYTE_ORDER 1234
>> +#define __LONG_MAX 0x7fffffffffffffffL
>> +
>> +TYPEDEF __builtin_va_list va_list;
>> +TYPEDEF __builtin_va_list __isoc_va_list;
>> +
>> +#ifndef __cplusplus
>> +TYPEDEF int wchar_t;
>> +#endif
>> +
>> +TYPEDEF float float_t;
>> +TYPEDEF double double_t;
>> +
>> +TYPEDEF struct { long long __ll; long double __ld; } max_align_t;
>> +
>> +TYPEDEF unsigned nlink_t;
> va_list and __isoc_va_list are no longer defined by the arch's
> alltypes.h.in, so they can be removed. I think the rest of that is ok.
>
>> diff --git a/arch/loongarch64/bits/fcntl.h b/arch/loongarch64/bits/fcntl.h
>> new file mode 100644
>> index 00000000..9bcbb7ff
>> --- /dev/null
>> +++ b/arch/loongarch64/bits/fcntl.h
>> @@ -0,0 +1,40 @@
>> +#define O_CREAT 0100
>> +#define O_EXCL 0200
>> +#define O_NOCTTY 0400
>> +#define O_TRUNC 01000
>> +#define O_APPEND 02000
>> +#define O_NONBLOCK 04000
>> +#define O_DSYNC 010000
>> +#define O_SYNC 04010000
>> +#define O_RSYNC 04010000
>> +#define O_DIRECTORY 0200000
>> +#define O_NOFOLLOW 0400000
>> +#define O_CLOEXEC 02000000
>> +
>> +#define O_ASYNC 020000
>> +#define O_DIRECT 040000
>> +#define O_LARGEFILE 0100000
>> +#define O_NOATIME 01000000
>> +#define O_PATH 010000000
>> +#define O_TMPFILE 020000000
>> +#define O_NDELAY O_NONBLOCK
>> +
>> +#define F_DUPFD 0
>> +#define F_GETFD 1
>> +#define F_SETFD 2
>> +#define F_GETFL 3
>> +#define F_SETFL 4
>> +
>> +#define F_SETOWN 8
>> +#define F_GETOWN 9
>> +#define F_SETSIG 10
>> +#define F_GETSIG 11
>> +
>> +#define F_GETLK 5
>> +#define F_SETLK 6
>> +#define F_SETLKW 7
>> +
>> +#define F_SETOWN_EX 15
>> +#define F_GETOWN_EX 16
>> +
>> +#define F_GETOWNER_UIDS 17
> AFAICT this file is identical to the generic one (with 32/64 bit #if
> evaluated already) so it can and should be dropped.
>
>> +++ b/arch/loongarch64/bits/signal.h
>> @@ -0,0 +1,79 @@
>> +#if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
>> + || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
>> +
>> +#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
>> +#define MINSIGSTKSZ 4096
>> +#define SIGSTKSZ 16384
>> +#endif
>> +
>> +typedef unsigned long greg_t, gregset_t[32];
>> +
>> +typedef struct sigcontext {
>> + unsigned long pc;
>> + gregset_t gregs;
>> + unsigned int flags;
>> + unsigned long extcontext[0] __attribute__((__aligned__(16)));
>> +}mcontext_t;
> [0] is not valid, and having a flexible array member here is possibly
> not even useful since I don't think it would be valid to access it via
> uc->uc_mcontext.extcontext[] since the instance of mcontext_t inside
> the ucontext struct does not have FAM space belonging to it, even if
> additional space was allocated past the end of the ucontext_t. In
> other words, I think compilers would be justified in treating attempts
> to access it this way as UB and optimizing them out.
>
>> diff --git a/arch/loongarch64/bits/stat.h b/arch/loongarch64/bits/stat.h
>> new file mode 100644
>> index 00000000..b620e142
>> --- /dev/null
>> +++ b/arch/loongarch64/bits/stat.h
>> @@ -0,0 +1,20 @@
>> +struct stat {
>> + dev_t st_dev;
>> + int __pad1[3];
>> + ino_t st_ino;
>> + mode_t st_mode;
>> + nlink_t st_nlink;
>> + uid_t st_uid;
>> + gid_t st_gid;
>> + dev_t st_rdev;
>> + unsigned int __pad2[2];
>> + off_t st_size;
>> + int __pad3;
>> + struct timespec st_atim;
>> + struct timespec st_mtim;
>> + struct timespec st_ctim;
>> + blksize_t st_blksize;
>> + unsigned int __pad4;
>> + blkcnt_t st_blocks;
>> + int __pad5[14];
>> +};
> __pad1[3] looks wrong -- st_ino will be aligned on a 64-bit boundary
> so there can't be an odd number of 32-bit ints before it. Naturally,
> it will be aligned with additional padding, but the intent here was
> probably to make all the padding explicit. Moreover, this isn't
> reflecting a kernel structure, just a userspace type that musl gets to
> define, so I'm not sure why it's being defined for a new arch with
> lots of gratuitous padding rather than just using a generic
> definition. I guess it was just copied from the mips64 one (which also
> has these problems).
>
> If you're already using this in production and don't want to break
> ABI, I don't see any real need to change it though. It doesn't really
> matter. Making it __pad1[4] would still be a good idea (and we should
> fix that on mips64) -- that doesn't break ABI.
>
>> diff --git a/arch/loongarch64/pthread_arch.h b/arch/loongarch64/pthread_arch.h
>> new file mode 100644
>> index 00000000..27f50e4c
>> --- /dev/null
>> +++ b/arch/loongarch64/pthread_arch.h
>> @@ -0,0 +1,13 @@
>> +static inline uintptr_t __get_tp()
>> +{
>> + uintptr_t tp;
>> + __asm__ ("or %0, $tp, $zero" : "=r" (tp) );
>> + return tp;
>> +}
>> +
>> +#define TLS_ABOVE_TP
>> +#define GAP_ABOVE_TP 0
>> +
>> +#define DTP_OFFSET 0
>> +
>> +#define MC_PC pc
> This can be done as something like:
>
> static inline uintptr_t __get_tp()
> {
> register uintptr_t tp __asm__("tp");
> __asm__ ("" : "=r" (tp) );
> return tp;
> }
>
> if the compiler doesn't botch it. Historically clang had trouble with
> that, so if that's the case, just stick with what you had -- it's not
> too costly doing a gratuitous move.
>
> Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 3:52 [musl] add loongarch64 port 王洪亮
2022-03-22 12:59 ` Rich Felker
@ 2022-03-22 19:03 ` Rich Felker
2022-03-22 20:36 ` Arnd Bergmann
2022-03-24 1:35 ` 王洪亮
2022-03-29 8:12 ` [musl] " 王洪亮
2 siblings, 2 replies; 52+ messages in thread
From: Rich Felker @ 2022-03-22 19:03 UTC (permalink / raw)
To: musl
On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
> diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
> new file mode 100644
> index 00000000..a28ec91a
> --- /dev/null
> +++ b/arch/loongarch64/bits/signal.h
> @@ -0,0 +1,79 @@
> [...]
> +#define _NSIG 64
It was also pointed out to me that this is likely wrong. _NSIG needs
to be 1 plus the last signal number, so 65 if there are 64 signals
like most archs have. Or, if you kept the mips weirdness, 128 (since
mips has 127 signals).
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 19:03 ` Rich Felker
@ 2022-03-22 20:36 ` Arnd Bergmann
2022-03-24 1:53 ` 王洪亮
2022-03-24 1:35 ` 王洪亮
1 sibling, 1 reply; 52+ messages in thread
From: Arnd Bergmann @ 2022-03-22 20:36 UTC (permalink / raw)
To: musl
On Tue, Mar 22, 2022 at 8:03 PM Rich Felker <dalias@libc.org> wrote:
>
> On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
> > diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
> > new file mode 100644
> > index 00000000..a28ec91a
> > --- /dev/null
> > +++ b/arch/loongarch64/bits/signal.h
> > @@ -0,0 +1,79 @@
> > [...]
> > +#define _NSIG 64
>
> It was also pointed out to me that this is likely wrong. _NSIG needs
> to be 1 plus the last signal number, so 65 if there are 64 signals
> like most archs have. Or, if you kept the mips weirdness, 128 (since
> mips has 127 signals).
The kernel port originally used the mips signal handling conventions,
but I pointed out during the review that this is not a good choice for
a new architecture.
The version that is currently under review for the kernel uses the
asm-generic version of all the ABI structures, with the normal 64
signals.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 20:36 ` Arnd Bergmann
@ 2022-03-24 1:53 ` 王洪亮
0 siblings, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-03-24 1:53 UTC (permalink / raw)
To: musl
Hi, Arnd
another team responsible for kernel port. I already put this point
to them for reference.
Hongliang Wang
在 2022/3/23 上午4:36, Arnd Bergmann 写道:
> On Tue, Mar 22, 2022 at 8:03 PM Rich Felker <dalias@libc.org> wrote:
>> On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
>>> diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
>>> new file mode 100644
>>> index 00000000..a28ec91a
>>> --- /dev/null
>>> +++ b/arch/loongarch64/bits/signal.h
>>> @@ -0,0 +1,79 @@
>>> [...]
>>> +#define _NSIG 64
>> It was also pointed out to me that this is likely wrong. _NSIG needs
>> to be 1 plus the last signal number, so 65 if there are 64 signals
>> like most archs have. Or, if you kept the mips weirdness, 128 (since
>> mips has 127 signals).
> The kernel port originally used the mips signal handling conventions,
> but I pointed out during the review that this is not a good choice for
> a new architecture.
>
> The version that is currently under review for the kernel uses the
> asm-generic version of all the ABI structures, with the normal 64
> signals.
>
> Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] add loongarch64 port
2022-03-22 19:03 ` Rich Felker
2022-03-22 20:36 ` Arnd Bergmann
@ 2022-03-24 1:35 ` 王洪亮
1 sibling, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-03-24 1:35 UTC (permalink / raw)
To: musl
Hi,
yes, this is a wrong. I fixed this error.
diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
index a28ec91a..e6613516 100644
--- a/arch/loongarch64/bits/signal.h
+++ b/arch/loongarch64/bits/signal.h
@@ -76,4 +76,4 @@ typedef struct __ucontext
#define SIGSYS 31
#define SIGUNUSED SIGSYS
-#define _NSIG 64
+#define _NSIG 65
--
Hongliang Wang
在 2022/3/23 上午3:03, Rich Felker 写道:
> On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
>> diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
>> new file mode 100644
>> index 00000000..a28ec91a
>> --- /dev/null
>> +++ b/arch/loongarch64/bits/signal.h
>> @@ -0,0 +1,79 @@
>> [...]
>> +#define _NSIG 64
> It was also pointed out to me that this is likely wrong. _NSIG needs
> to be 1 plus the last signal number, so 65 if there are 64 signals
> like most archs have. Or, if you kept the mips weirdness, 128 (since
> mips has 127 signals).
>
> Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* [musl] Re: add loongarch64 port
2022-03-22 3:52 [musl] add loongarch64 port 王洪亮
2022-03-22 12:59 ` Rich Felker
2022-03-22 19:03 ` Rich Felker
@ 2022-03-29 8:12 ` 王洪亮
2022-03-29 8:26 ` Arnd Bergmann
2 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-03-29 8:12 UTC (permalink / raw)
To: musl
Hi,
we have published 0001-add-loongarch64-port-v2.patch in
https://github.com/loongson/musl/tree/loongarch-v1.0.
The patch v2 fixed the issues pointed out in v1.
have any other issues to modify?
Please code review, thanks.
Hongliang Wang
在 2022/3/22 上午11:52, 王洪亮 写道:
> Hi,
>
> Thank you for give us some useful suggestions on the first submit
>
> from 翟小娟 <zhaixiaojuan@loongson.cn>.
>
> we review code and make changes on code specification, code style
>
> and code errors.
>
>
> The new patch has been published in
>
> https://github.com/loongson/musl/tree/loongarch-v1.0.
>
>
> The linux kernel has been published in
>
> https://github.com/loongson/linux/tree/loongarch-next.
>
>
> we alse published gcc, glibc in https://github.com/loongson
>
> and submitting to the community.
>
>
> we can supply a physical machine remote login for test musl.
>
> It has been compiled and run the libc-test successfully.
>
>
> Please code review, thanks!
>
>
> Hongliang Wang
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-03-29 8:12 ` [musl] " 王洪亮
@ 2022-03-29 8:26 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2022-03-29 8:26 UTC (permalink / raw)
To: musl
On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>
> Hi,
>
> we have published 0001-add-loongarch64-port-v2.patch in
>
> https://github.com/loongson/musl/tree/loongarch-v1.0.
>
> The patch v2 fixed the issues pointed out in v1.
>
> have any other issues to modify?
I see you still refer to the system calls that I asked to be removed from
the kernel: clone() and the old stat() family (pre-statx). Please use
only the system calls that are actually supported in mainline kernels,
otherwise it does not work.
For the signal list, the stdint.h header, and the 'struct stat' and
'struct kstat'
definitions, I would expect that there is already an architecture-independent
definition in musl that you can use, as these should be the same for
all new architectures.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
@ 2022-03-31 6:20 王洪亮
2022-03-31 8:14 ` Arnd Bergmann
2022-03-31 18:47 ` Rich Felker
0 siblings, 2 replies; 52+ messages in thread
From: 王洪亮 @ 2022-03-31 6:20 UTC (permalink / raw)
To: musl
在 2022/3/29 下午4:26, Arnd Bergmann 写道:
> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> Hi,
>>
>> we have published 0001-add-loongarch64-port-v2.patch in
>>
>> https://github.com/loongson/musl/tree/loongarch-v1.0.
>>
>> The patch v2 fixed the issues pointed out in v1.
>>
>> have any other issues to modify?
> I see you still refer to the system calls that I asked to be removed from
> the kernel: clone() and the old stat() family (pre-statx). Please use
> only the system calls that are actually supported in mainline kernels,
> otherwise it does not work.
Hi, Arnd
I understand the new system call is clone3() ?
I found musl does not support the clone3() call now, I can implement the
clone3() in LoongArch for future called.
I do not understand what is old stat() family (pre-statx) ? what is new ?
I compare the system call that related the stat in musl and mainline
kernel 5.17,
they are consistent.
#define __NR3264_statfs 43 /*sys_statfs*/
#define __NR3264_fstatfs 44 /*sys_fstatfs*/
#define __NR3264_fstatat 79 /*sys_newfstatat*/
#define __NR3264_fstat 80 /*sys_newfstat*/
#define __NR_statx 291 /*sys_statx*/
#define __NR_statfs __NR3264_statfs
#define __NR_fstatfs __NR3264_fstatfs
#define __NR_newfstatat __NR3264_fstatat
#define __NR_fstat __NR3264_fstat
> For the signal list, the stdint.h header, and the 'struct stat' and
> 'struct kstat'
> definitions, I would expect that there is already an architecture-independent
> definition in musl that you can use, as these should be the same for
> all new architectures.
I understand the meaning is define signal.h, stdint.h, struct stat and
struct kstat in generic,
LoongArch use the generic definition.
can we deal with this issue separately ?
1.LoongArch port based on the existing software framework in musl.
2.implement the generic definitions in musl, LoongArch use the
architecture-independent definition.
Hongliang Wang.
>
> Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-03-31 6:20 王洪亮
@ 2022-03-31 8:14 ` Arnd Bergmann
2022-04-01 7:40 ` 王洪亮
2022-04-27 1:58 ` 王洪亮
2022-03-31 18:47 ` Rich Felker
1 sibling, 2 replies; 52+ messages in thread
From: Arnd Bergmann @ 2022-03-31 8:14 UTC (permalink / raw)
To: musl
On Thu, Mar 31, 2022 at 8:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
> > On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> I do not understand what is old stat() family (pre-statx) ? what is new ?
>
> I compare the system call that related the stat in musl and mainline
> kernel 5.17,
>
> they are consistent.
>
> #define __NR3264_statfs 43 /*sys_statfs*/
> #define __NR3264_fstatfs 44 /*sys_fstatfs*/
> #define __NR3264_fstatat 79 /*sys_newfstatat*/
> #define __NR3264_fstat 80 /*sys_newfstat*/
> #define __NR_statx 291 /*sys_statx*/
> #define __NR_statfs __NR3264_statfs
> #define __NR_fstatfs __NR3264_fstatfs
> #define __NR_newfstatat __NR3264_fstatat
> #define __NR_fstat __NR3264_fstat
The __NR_fstat and __NR_newfstatat symbols are only defined by
the kernel if __ARCH_WANT_NEW_STAT is set, which should not be
by the time the kernel port is merged. Instead, user space should
call statx() here, which continues to be supported as a superset.
The statfs/fstatfs system calls are unrelated and can be used, the proposed
fsinfo() system call that was meant as a replacement has never made
it in
> > For the signal list, the stdint.h header, and the 'struct stat' and
> > 'struct kstat'
> > definitions, I would expect that there is already an architecture-independent
> > definition in musl that you can use, as these should be the same for
> > all new architectures.
>
> I understand the meaning is define signal.h, stdint.h, struct stat and
> struct kstat in generic,
>
> LoongArch use the generic definition.
>
> can we deal with this issue separately ?
>
> 1.LoongArch port based on the existing software framework in musl.
>
> 2.implement the generic definitions in musl, LoongArch use the
>
> architecture-independent definition.
Yes, that works for me, I only care about the ABI issues: we have to
ensure that the kernel interfaces in the upstream musl port are
the same ones that are used in the upstream kernel port, to avoid
breaking applications built on these after everything is upstream.
(We can break compatibility with existing non-upstream user space
for the moment, which is the point of this review).
Any implementation details within musl that do not impact the ABI
can come later. I mainly pointed out these three because I expected
them to already have generic code in musl, given that the kernel does
not require architecture specific definitions for these. If you have custom
definitions, that introduces a certain risk that these correspond to an
earlier private kernel version of yours rather than what will become
the official port.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-03-31 8:14 ` Arnd Bergmann
@ 2022-04-01 7:40 ` 王洪亮
2022-04-01 7:48 ` Arnd Bergmann
2022-04-27 1:58 ` 王洪亮
1 sibling, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-01 7:40 UTC (permalink / raw)
To: musl
在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> On Thu, Mar 31, 2022 at 8:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
>>> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> I do not understand what is old stat() family (pre-statx) ? what is new ?
>>
>> I compare the system call that related the stat in musl and mainline
>> kernel 5.17,
>>
>> they are consistent.
>>
>> #define __NR3264_statfs 43 /*sys_statfs*/
>> #define __NR3264_fstatfs 44 /*sys_fstatfs*/
>> #define __NR3264_fstatat 79 /*sys_newfstatat*/
>> #define __NR3264_fstat 80 /*sys_newfstat*/
>> #define __NR_statx 291 /*sys_statx*/
>> #define __NR_statfs __NR3264_statfs
>> #define __NR_fstatfs __NR3264_fstatfs
>> #define __NR_newfstatat __NR3264_fstatat
>> #define __NR_fstat __NR3264_fstat
> The __NR_fstat and __NR_newfstatat symbols are only defined by
> the kernel if __ARCH_WANT_NEW_STAT is set, which should not be
> by the time the kernel port is merged. Instead, user space should
> call statx() here, which continues to be supported as a superset.
>
> The statfs/fstatfs system calls are unrelated and can be used, the proposed
> fsinfo() system call that was meant as a replacement has never made
> it in
>
>>> For the signal list, the stdint.h header, and the 'struct stat' and
>>> 'struct kstat'
>>> definitions, I would expect that there is already an architecture-independent
>>> definition in musl that you can use, as these should be the same for
>>> all new architectures.
>> I understand the meaning is define signal.h, stdint.h, struct stat and
>> struct kstat in generic,
>>
>> LoongArch use the generic definition.
>>
>> can we deal with this issue separately ?
>>
>> 1.LoongArch port based on the existing software framework in musl.
>>
>> 2.implement the generic definitions in musl, LoongArch use the
>>
>> architecture-independent definition.
> Yes, that works for me, I only care about the ABI issues: we have to
> ensure that the kernel interfaces in the upstream musl port are
> the same ones that are used in the upstream kernel port, to avoid
> breaking applications built on these after everything is upstream.
> (We can break compatibility with existing non-upstream user space
> for the moment, which is the point of this review).
>
> Any implementation details within musl that do not impact the ABI
> can come later. I mainly pointed out these three because I expected
> them to already have generic code in musl, given that the kernel does
> not require architecture specific definitions for these. If you have custom
> definitions, that introduces a certain risk that these correspond to an
> earlier private kernel version of yours rather than what will become
> the official port.
>
> Arnd
Hi, Arnd
In kernel port, loongarch64 use the generic struct stat.
loongarch64 define struct stat and kstat in musl is consistent with
generic stat in kernel.
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-01 7:40 ` 王洪亮
@ 2022-04-01 7:48 ` Arnd Bergmann
2022-04-02 6:19 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-01 7:48 UTC (permalink / raw)
To: musl
On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
>
> In kernel port, loongarch64 use the generic struct stat.
>
> loongarch64 define struct stat and kstat in musl is consistent with
>
> generic stat in kernel.
My point was that I asked for these to be removed in
https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/
With __NR_newfstatat and __NR_fstat gone from the system
call list, there is no 'struct stat' that is exposed by the kernel.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-01 7:48 ` Arnd Bergmann
@ 2022-04-02 6:19 ` 王洪亮
2022-04-02 7:21 ` Rich Felker
0 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-02 6:19 UTC (permalink / raw)
To: musl
Hi, Arnd
I found it has not been removed from system call list in kernel yet.
I wonder if I could keep consistent with the current status of the kernel
for the time being,and modify as the kernel changes.
Hongliang Wang
在 2022/4/1 下午3:48, Arnd Bergmann 写道:
> On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
>>
>> In kernel port, loongarch64 use the generic struct stat.
>>
>> loongarch64 define struct stat and kstat in musl is consistent with
>>
>> generic stat in kernel.
> My point was that I asked for these to be removed in
>
> https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/
>
> With __NR_newfstatat and __NR_fstat gone from the system
> call list, there is no 'struct stat' that is exposed by the kernel.
>
> Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-02 6:19 ` 王洪亮
@ 2022-04-02 7:21 ` Rich Felker
2022-04-02 9:53 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-04-02 7:21 UTC (permalink / raw)
To: 王洪亮; +Cc: musl
On Sat, Apr 02, 2022 at 02:19:44PM +0800, 王洪亮 wrote:
> Hi, Arnd
>
> I found it has not been removed from system call list in kernel yet.
> I wonder if I could keep consistent with the current status of the kernel
> for the time being,and modify as the kernel changes.
As I understand it, no -- musl targets the permanent kernel syscall
API/ABI for the arch. So if the legacy stat syscall is not going to be
part of the interface that's approved upstream in the kernel for this
arch, musl can't be using it.
Am I correct in understanding that the syscall & struct stat that are
"there now" are part of a proposed port that's not yet upstream, and
that upstream maintainers are asking for them to be removed as part of
accepting the port?
> 在 2022/4/1 下午3:48, Arnd Bergmann 写道:
> >On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> >>在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> >>
> >>In kernel port, loongarch64 use the generic struct stat.
> >>
> >>loongarch64 define struct stat and kstat in musl is consistent with
> >>
> >>generic stat in kernel.
> >My point was that I asked for these to be removed in
> >
> >https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/
> >
> >With __NR_newfstatat and __NR_fstat gone from the system
> >call list, there is no 'struct stat' that is exposed by the kernel.
> >
> > Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-02 7:21 ` Rich Felker
@ 2022-04-02 9:53 ` 王洪亮
0 siblings, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-04-02 9:53 UTC (permalink / raw)
To: musl
在 2022/4/2 下午3:21, Rich Felker 写道:
> On Sat, Apr 02, 2022 at 02:19:44PM +0800, 王洪亮 wrote:
>> Hi, Arnd
>>
>> I found it has not been removed from system call list in kernel yet.
>> I wonder if I could keep consistent with the current status of the kernel
>> for the time being,and modify as the kernel changes.
> As I understand it, no -- musl targets the permanent kernel syscall
> API/ABI for the arch. So if the legacy stat syscall is not going to be
> part of the interface that's approved upstream in the kernel for this
> arch, musl can't be using it.
>
> Am I correct in understanding that the syscall & struct stat that are
> "there now" are part of a proposed port that's not yet upstream, and
> that upstream maintainers are asking for them to be removed as part of
> accepting the port?
>
Hi, Rich
yes, but it has not been removed from kernel port yet,the Author hopes
to keep it,so I consider modify it when the issue comes to a conclusion.
Hongliang Wang
>> 在 2022/4/1 下午3:48, Arnd Bergmann 写道:
>>> On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>>>> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
>>>>
>>>> In kernel port, loongarch64 use the generic struct stat.
>>>>
>>>> loongarch64 define struct stat and kstat in musl is consistent with
>>>>
>>>> generic stat in kernel.
>>> My point was that I asked for these to be removed in
>>>
>>> https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/
>>>
>>> With __NR_newfstatat and __NR_fstat gone from the system
>>> call list, there is no 'struct stat' that is exposed by the kernel.
>>>
>>> Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-03-31 8:14 ` Arnd Bergmann
2022-04-01 7:40 ` 王洪亮
@ 2022-04-27 1:58 ` 王洪亮
2022-04-27 2:13 ` Rich Felker
1 sibling, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-27 1:58 UTC (permalink / raw)
To: musl
在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> The __NR_fstat and __NR_newfstatat symbols are only defined by
> the kernel if __ARCH_WANT_NEW_STAT is set, which should not be
> by the time the kernel port is merged. Instead, user space should
> call statx() here, which continues to be supported as a superset.
>
>
> Arnd
there is a build error if I remove __NR_fstat and __NR_newfstatat,
the architecture-independent code depends on the __NR_fstat and
__NR_fstatat defined in architecture platform.
How to deal with this issue?
In file included from src/stat/fstatat.c:8:
src/stat/fstatat.c: In function ‘fstatat_kstat’:
src/stat/fstatat.c:78:19: error: ‘SYS_fstat’ undeclared (first use in
this function); did you mean ‘SYS_statx’?
ret = __syscall(SYS_fstat, fd, &kst);
src/stat/fstatat.c:80:20: error: ‘SYS_fstatat’ undeclared (first use in
this function); did you mean ‘SYS_fstatfs’?
ret = __syscall(SYS_fstatat, fd, path, &kst, flag);
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-27 1:58 ` 王洪亮
@ 2022-04-27 2:13 ` Rich Felker
0 siblings, 0 replies; 52+ messages in thread
From: Rich Felker @ 2022-04-27 2:13 UTC (permalink / raw)
To: 王洪亮; +Cc: musl
On Wed, Apr 27, 2022 at 09:58:44AM +0800, 王洪亮 wrote:
>
> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> >The __NR_fstat and __NR_newfstatat symbols are only defined by
> >the kernel if __ARCH_WANT_NEW_STAT is set, which should not be
> >by the time the kernel port is merged. Instead, user space should
> >call statx() here, which continues to be supported as a superset.
> >
> >
> > Arnd
>
> there is a build error if I remove __NR_fstat and __NR_newfstatat,
> the architecture-independent code depends on the __NR_fstat and
> __NR_fstatat defined in architecture platform.
> How to deal with this issue?
>
> In file included from src/stat/fstatat.c:8:
> src/stat/fstatat.c: In function ‘fstatat_kstat’:
> src/stat/fstatat.c:78:19: error: ‘SYS_fstat’ undeclared (first use
> in this function); did you mean ‘SYS_statx’?
> ret = __syscall(SYS_fstat, fd, &kst);
>
> src/stat/fstatat.c:80:20: error: ‘SYS_fstatat’ undeclared (first use
> in this function); did you mean ‘SYS_fstatfs’?
>
> ret = __syscall(SYS_fstatat, fd, path, &kst, flag);
There are pending changes that are needed for riscv32 that address
the same issue there. I'll review them again in the next couple days
and either merge them or make alternative changes to make the rest of
musl not assume the existence of these syscalls.
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-03-31 6:20 王洪亮
2022-03-31 8:14 ` Arnd Bergmann
@ 2022-03-31 18:47 ` Rich Felker
2022-04-02 7:59 ` 王洪亮
1 sibling, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-03-31 18:47 UTC (permalink / raw)
To: 王洪亮; +Cc: musl
On Thu, Mar 31, 2022 at 02:20:51PM +0800, 王洪亮 wrote:
> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
> >On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> >>Hi,
> >>
> >>we have published 0001-add-loongarch64-port-v2.patch in
> >>
> >>https://github.com/loongson/musl/tree/loongarch-v1.0.
> >>
> >>The patch v2 fixed the issues pointed out in v1.
> >>
> >>have any other issues to modify?
> >I see you still refer to the system calls that I asked to be removed from
> >the kernel: clone() and the old stat() family (pre-statx). Please use
> >only the system calls that are actually supported in mainline kernels,
> >otherwise it does not work.
> Hi, Arnd
>
> I understand the new system call is clone3() ?
>
> I found musl does not support the clone3() call now, I can implement the
>
> clone3() in LoongArch for future called.
The point isn't that there should be a clone3() function (there
shouldn't) but that __clone has to be implemented by making the
__NR_clone3 syscall not the (nonexistant) __NR_clone syscall.
> I do not understand what is old stat() family (pre-statx) ? what is new ?
>
> I compare the system call that related the stat in musl and
> mainline kernel 5.17,
>
> they are consistent.
>
> #define __NR3264_statfs 43 /*sys_statfs*/
> #define __NR3264_fstatfs 44 /*sys_fstatfs*/
> #define __NR3264_fstatat 79 /*sys_newfstatat*/
> #define __NR3264_fstat 80 /*sys_newfstat*/
> #define __NR_statx 291 /*sys_statx*/
> #define __NR_statfs __NR3264_statfs
> #define __NR_fstatfs __NR3264_fstatfs
> #define __NR_newfstatat __NR3264_fstatat
> #define __NR_fstat __NR3264_fstat
>
>
> >For the signal list, the stdint.h header, and the 'struct stat' and
> >'struct kstat'
> >definitions, I would expect that there is already an architecture-independent
> >definition in musl that you can use, as these should be the same for
> >all new architectures.
>
> I understand the meaning is define signal.h, stdint.h, struct stat
> and struct kstat in generic,
I don't think we have generics for all of these yet, and what some of
them should be is not clear -- for example, generic kstat should
probably match the statx structure on 32-bit archs. I actually need to
figure some of this out as part of merging the rv32 port. So, for now,
it's probably ok for the loongarch64 port to keep its own copies of
the ones that don't yet have generics, and leave deduplication as
separate task to be done later.
However, for struct stat (musl userspace), I think it would be nice to
use a definition that matches the intended "generic" one (the one
riscv64 and aarch64 use).
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-03-31 18:47 ` Rich Felker
@ 2022-04-02 7:59 ` 王洪亮
2022-04-06 2:08 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-02 7:59 UTC (permalink / raw)
To: musl
在 2022/4/1 上午2:47, Rich Felker 写道:
> On Thu, Mar 31, 2022 at 02:20:51PM +0800, 王洪亮 wrote:
>> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
>>> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>>>> Hi,
>>>>
>>>> we have published 0001-add-loongarch64-port-v2.patch in
>>>>
>>>> https://github.com/loongson/musl/tree/loongarch-v1.0.
>>>>
>>>> The patch v2 fixed the issues pointed out in v1.
>>>>
>>>> have any other issues to modify?
>>> I see you still refer to the system calls that I asked to be removed from
>>> the kernel: clone() and the old stat() family (pre-statx). Please use
>>> only the system calls that are actually supported in mainline kernels,
>>> otherwise it does not work.
>> Hi, Arnd
>>
>> I understand the new system call is clone3() ?
>>
>> I found musl does not support the clone3() call now, I can implement the
>>
>> clone3() in LoongArch for future called.
> The point isn't that there should be a clone3() function (there
> shouldn't) but that __clone has to be implemented by making the
> __NR_clone3 syscall not the (nonexistant) __NR_clone syscall.
> Rich
Hi, Rich
I understand the meaning is that keep the architecture-independent code
and the __clone input parameter unchanged,within the __clone, convert
input parameter to clone3 parameter, and then __NR_clone3 syscall.
will that confusion between clone and clone3?
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-02 7:59 ` 王洪亮
@ 2022-04-06 2:08 ` 王洪亮
2022-04-06 16:00 ` Markus Wichmann
0 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-06 2:08 UTC (permalink / raw)
To: musl
在 2022/4/2 下午3:59, 王洪亮 写道:
>
> 在 2022/4/1 上午2:47, Rich Felker 写道:
>> On Thu, Mar 31, 2022 at 02:20:51PM +0800, 王洪亮 wrote:
>>> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
>>>> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> we have published 0001-add-loongarch64-port-v2.patch in
>>>>>
>>>>> https://github.com/loongson/musl/tree/loongarch-v1.0.
>>>>>
>>>>> The patch v2 fixed the issues pointed out in v1.
>>>>>
>>>>> have any other issues to modify?
>>>> I see you still refer to the system calls that I asked to be
>>>> removed from
>>>> the kernel: clone() and the old stat() family (pre-statx). Please use
>>>> only the system calls that are actually supported in mainline kernels,
>>>> otherwise it does not work.
>>> Hi, Arnd
>>>
>>> I understand the new system call is clone3() ?
>>>
>>> I found musl does not support the clone3() call now, I can implement
>>> the
>>>
>>> clone3() in LoongArch for future called.
>> The point isn't that there should be a clone3() function (there
>> shouldn't) but that __clone has to be implemented by making the
>> __NR_clone3 syscall not the (nonexistant) __NR_clone syscall.
>> Rich
>
>
> Hi, Rich
>
>
> I understand the meaning is that keep the architecture-independent code
> and the __clone input parameter unchanged,within the __clone, convert
> input parameter to clone3 parameter, and then __NR_clone3 syscall.
>
> will that confusion between clone and clone3?
>
>
> Hongliang Wang
Hi, Rich
within __clone() implement __NR_clone3 syscall,
will that confusion between clone and clone3?
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-06 2:08 ` 王洪亮
@ 2022-04-06 16:00 ` Markus Wichmann
2022-04-08 2:21 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Markus Wichmann @ 2022-04-06 16:00 UTC (permalink / raw)
To: musl
On Wed, Apr 06, 2022 at 10:08:24AM +0800, 王洪亮 wrote:
> Hi, Rich
>
>
> within __clone() implement __NR_clone3 syscall,
>
> will that confusion between clone and clone3?
>
>
> Hongliang Wang
>
>
>
__clone() is a function with a defined interface. How it is implemented
is not given in the name. Why should __clone() have to be implemented
using the SYS_clone system call? If I understood the thread so far
correctly, the final kernel will not even have SYS_clone.
Compare with open(), which is often implemented in terms of SYS_openat
instead of SYS_open. Or qsort(), which, despite the name, is rarely
implemented as a quicksort.
So no, there will be no confusion of system calls because a function is
not implemented in terms of the system call of the same name, as long as
the function fulfills the defined interface.
Ciao,
Markus
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-06 16:00 ` Markus Wichmann
@ 2022-04-08 2:21 ` 王洪亮
2022-04-08 6:46 ` Arnd Bergmann
0 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-08 2:21 UTC (permalink / raw)
To: musl
在 2022/4/7 上午12:00, Markus Wichmann 写道:
> On Wed, Apr 06, 2022 at 10:08:24AM +0800, 王洪亮 wrote:
>> Hi, Rich
>>
>>
>> within __clone() implement __NR_clone3 syscall,
>>
>> will that confusion between clone and clone3?
>>
>>
>> Hongliang Wang
>>
>>
>>
> __clone() is a function with a defined interface. How it is implemented
> is not given in the name. Why should __clone() have to be implemented
> using the SYS_clone system call? If I understood the thread so far
> correctly, the final kernel will not even have SYS_clone.
>
> Compare with open(), which is often implemented in terms of SYS_openat
> instead of SYS_open. Or qsort(), which, despite the name, is rarely
> implemented as a quicksort.
>
> So no, there will be no confusion of system calls because a function is
> not implemented in terms of the system call of the same name, as long as
> the function fulfills the defined interface.
>
> Ciao,
> Markus
Hi,
I agree this point.
In the implementation,I found a problem:
In order to implement __NR_clone3 syscall in __clone(),
I need to fill struct clone_args,I found clone_args.stack
point to the lowest address of stack,but the input parameter
"stack" of __clone() point to stack bottom(STACK_GROWS_DOWN),
because of no stack_size,I can't convert between them.
Do you have any good suggestions?
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-08 2:21 ` 王洪亮
@ 2022-04-08 6:46 ` Arnd Bergmann
2022-04-09 3:54 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-08 6:46 UTC (permalink / raw)
To: musl, Christian Brauner
On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/4/7 上午12:00, Markus Wichmann 写道:
> > On Wed, Apr 06, 2022 at 10:08:24AM +0800, 王洪亮 wrote:
> >> Hi, Rich
> >>
> >>
> >> within __clone() implement __NR_clone3 syscall,
> >>
> >> will that confusion between clone and clone3?
> >>
> >>
> >> Hongliang Wang
> >>
> >>
> >>
> > __clone() is a function with a defined interface. How it is implemented
> > is not given in the name. Why should __clone() have to be implemented
> > using the SYS_clone system call? If I understood the thread so far
> > correctly, the final kernel will not even have SYS_clone.
> >
> > Compare with open(), which is often implemented in terms of SYS_openat
> > instead of SYS_open. Or qsort(), which, despite the name, is rarely
> > implemented as a quicksort.
> >
> > So no, there will be no confusion of system calls because a function is
> > not implemented in terms of the system call of the same name, as long as
> > the function fulfills the defined interface.
> >
> > Ciao,
> > Markus
>
> Hi,
>
> I agree this point.
> In the implementation,I found a problem:
> In order to implement __NR_clone3 syscall in __clone(),
> I need to fill struct clone_args,I found clone_args.stack
> point to the lowest address of stack,but the input parameter
> "stack" of __clone() point to stack bottom(STACK_GROWS_DOWN),
> because of no stack_size,I can't convert between them.
> Do you have any good suggestions?
There is a good explanation from Christian Brauner about this in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
What happens in the clone() syscall in the kernel is that the size
gets added to the initial pointer on normal architectures (parisc and ia64
being the exceptions). If you already have the stack pointer, I think you can
just pass size=0 as we do internally in the kernel.
If there was a port of musl to one of the architectures that does it
differently,
then changing callers such as
pid = __clone(child, stack+sizeof stack,
CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
would be required, and the separate size argument in clone3() could
help keep that hidden from musl.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-08 6:46 ` Arnd Bergmann
@ 2022-04-09 3:54 ` 王洪亮
2022-04-09 11:06 ` Arnd Bergmann
0 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-09 3:54 UTC (permalink / raw)
To: musl
在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> 在 2022/4/7 上午12:00, Markus Wichmann 写道:
>>> On Wed, Apr 06, 2022 at 10:08:24AM +0800, 王洪亮 wrote:
>>>> Hi, Rich
>>>>
>>>>
>>>> within __clone() implement __NR_clone3 syscall,
>>>>
>>>> will that confusion between clone and clone3?
>>>>
>>>>
>>>> Hongliang Wang
>>>>
>>>>
>>>>
>>> __clone() is a function with a defined interface. How it is implemented
>>> is not given in the name. Why should __clone() have to be implemented
>>> using the SYS_clone system call? If I understood the thread so far
>>> correctly, the final kernel will not even have SYS_clone.
>>>
>>> Compare with open(), which is often implemented in terms of SYS_openat
>>> instead of SYS_open. Or qsort(), which, despite the name, is rarely
>>> implemented as a quicksort.
>>>
>>> So no, there will be no confusion of system calls because a function is
>>> not implemented in terms of the system call of the same name, as long as
>>> the function fulfills the defined interface.
>>>
>>> Ciao,
>>> Markus
>> Hi,
>>
>> I agree this point.
>> In the implementation,I found a problem:
>> In order to implement __NR_clone3 syscall in __clone(),
>> I need to fill struct clone_args,I found clone_args.stack
>> point to the lowest address of stack,but the input parameter
>> "stack" of __clone() point to stack bottom(STACK_GROWS_DOWN),
>> because of no stack_size,I can't convert between them.
>> Do you have any good suggestions?
> There is a good explanation from Christian Brauner about this in
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
>
> What happens in the clone() syscall in the kernel is that the size
> gets added to the initial pointer on normal architectures (parisc and ia64
> being the exceptions). If you already have the stack pointer, I think you can
> just pass size=0 as we do internally in the kernel.
>
> If there was a port of musl to one of the architectures that does it
> differently,
> then changing callers such as
>
> pid = __clone(child, stack+sizeof stack,
> CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
>
> would be required, and the separate size argument in clone3() could
> help keep that hidden from musl.
>
> Arnd
In LoongArch,the stack is grows down.
As previous suggested,I implement __NR_clone3 syscall within __clone()
in loongarch port,based on __clone() interface unchanged and the
architecture-independent code of call __clone() unchanged.
In __NR_clone3 syscall,I need pass the lowest address of memory area to
clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
must not be 0)
if (kargs->stack_size == 0)
return false;
current,the __clone()'s input parameters have no "stack_size",so I can't
pass valid(must be size!=0) stack_size to clone3.
your meaning is pass stack_size=0 when the input parameter "stack" of
__clone()
is already stack point? but pass stack_size=0 is illegal.
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-09 3:54 ` 王洪亮
@ 2022-04-09 11:06 ` Arnd Bergmann
2022-04-09 13:19 ` Rich Felker
2022-04-11 3:40 ` 王洪亮
0 siblings, 2 replies; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-09 11:06 UTC (permalink / raw)
To: musl, Christian Brauner
On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
> >
> > What happens in the clone() syscall in the kernel is that the size
> > gets added to the initial pointer on normal architectures (parisc and ia64
> > being the exceptions). If you already have the stack pointer, I think you can
> > just pass size=0 as we do internally in the kernel.
> >
> > If there was a port of musl to one of the architectures that does it
> > differently,
> > then changing callers such as
> >
> > pid = __clone(child, stack+sizeof stack,
> > CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
> >
> > would be required, and the separate size argument in clone3() could
> > help keep that hidden from musl.
> >
> > Arnd
>
>
> In LoongArch,the stack is grows down.
>
> As previous suggested,I implement __NR_clone3 syscall within __clone()
> in loongarch port,based on __clone() interface unchanged and the
> architecture-independent code of call __clone() unchanged.
>
> In __NR_clone3 syscall,I need pass the lowest address of memory area to
> clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> must not be 0)
> if (kargs->stack_size == 0)
> return false;
>
> current,the __clone()'s input parameters have no "stack_size",so I can't
> pass valid(must be size!=0) stack_size to clone3.
>
> your meaning is pass stack_size=0 when the input parameter "stack" of
> __clone()
> is already stack point? but pass stack_size=0 is illegal.
Ah, you are right, that doesn't work at the moment. You dropped Christian
from the Cc list, adding him back because he probably has an idea
for how to address that.
It looks like it could be fixed for the internal callers of __clone() by
adding a __clone3() call that takes the size argument, and falls back
to calling __clone() on architectures that have that. I don't see how
one would do it for the generic clone() library function call though.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-09 11:06 ` Arnd Bergmann
@ 2022-04-09 13:19 ` Rich Felker
2022-04-09 13:30 ` Rich Felker
2022-04-13 7:19 ` Christian Brauner
2022-04-11 3:40 ` 王洪亮
1 sibling, 2 replies; 52+ messages in thread
From: Rich Felker @ 2022-04-09 13:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: musl, Christian Brauner
On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
> > >
> > > What happens in the clone() syscall in the kernel is that the size
> > > gets added to the initial pointer on normal architectures (parisc and ia64
> > > being the exceptions). If you already have the stack pointer, I think you can
> > > just pass size=0 as we do internally in the kernel.
> > >
> > > If there was a port of musl to one of the architectures that does it
> > > differently,
> > > then changing callers such as
> > >
> > > pid = __clone(child, stack+sizeof stack,
> > > CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
> > >
> > > would be required, and the separate size argument in clone3() could
> > > help keep that hidden from musl.
> > >
> > > Arnd
> >
> >
> > In LoongArch,the stack is grows down.
> >
> > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > in loongarch port,based on __clone() interface unchanged and the
> > architecture-independent code of call __clone() unchanged.
> >
> > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > must not be 0)
> > if (kargs->stack_size == 0)
> > return false;
> >
> > current,the __clone()'s input parameters have no "stack_size",so I can't
> > pass valid(must be size!=0) stack_size to clone3.
> >
> > your meaning is pass stack_size=0 when the input parameter "stack" of
> > __clone()
> > is already stack point? but pass stack_size=0 is illegal.
>
> Ah, you are right, that doesn't work at the moment. You dropped Christian
> from the Cc list, adding him back because he probably has an idea
> for how to address that.
>
> It looks like it could be fixed for the internal callers of __clone() by
> adding a __clone3() call that takes the size argument, and falls back
> to calling __clone() on architectures that have that. I don't see how
> one would do it for the generic clone() library function call though.
size=4k and passing stack-4k? O_o
This seems like a ridiculous kernel regression to require a size when
none may be available...
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-09 13:19 ` Rich Felker
@ 2022-04-09 13:30 ` Rich Felker
2022-04-10 10:30 ` Arnd Bergmann
2022-04-13 7:19 ` Christian Brauner
1 sibling, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-04-09 13:30 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: musl, Christian Brauner
On Sat, Apr 09, 2022 at 09:19:39AM -0400, Rich Felker wrote:
> On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
> > > >
> > > > What happens in the clone() syscall in the kernel is that the size
> > > > gets added to the initial pointer on normal architectures (parisc and ia64
> > > > being the exceptions). If you already have the stack pointer, I think you can
> > > > just pass size=0 as we do internally in the kernel.
> > > >
> > > > If there was a port of musl to one of the architectures that does it
> > > > differently,
> > > > then changing callers such as
> > > >
> > > > pid = __clone(child, stack+sizeof stack,
> > > > CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
> > > >
> > > > would be required, and the separate size argument in clone3() could
> > > > help keep that hidden from musl.
> > > >
> > > > Arnd
> > >
> > >
> > > In LoongArch,the stack is grows down.
> > >
> > > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > > in loongarch port,based on __clone() interface unchanged and the
> > > architecture-independent code of call __clone() unchanged.
> > >
> > > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > > must not be 0)
> > > if (kargs->stack_size == 0)
> > > return false;
> > >
> > > current,the __clone()'s input parameters have no "stack_size",so I can't
> > > pass valid(must be size!=0) stack_size to clone3.
> > >
> > > your meaning is pass stack_size=0 when the input parameter "stack" of
> > > __clone()
> > > is already stack point? but pass stack_size=0 is illegal.
> >
> > Ah, you are right, that doesn't work at the moment. You dropped Christian
> > from the Cc list, adding him back because he probably has an idea
> > for how to address that.
> >
> > It looks like it could be fixed for the internal callers of __clone() by
> > adding a __clone3() call that takes the size argument, and falls back
> > to calling __clone() on architectures that have that. I don't see how
> > one would do it for the generic clone() library function call though.
>
> size=4k and passing stack-4k? O_o
>
> This seems like a ridiculous kernel regression to require a size when
> none may be available...
Actually, if there aren't yet archs lacking SYS_clone, this API
regression may be a good argument not to drop SYS_clone on new archs
yet until there's a way for new archs to get the same behavior
(unspecified stack size).
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-09 13:30 ` Rich Felker
@ 2022-04-10 10:30 ` Arnd Bergmann
2022-04-10 15:26 ` Rich Felker
2022-04-13 7:26 ` Christian Brauner
0 siblings, 2 replies; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-10 10:30 UTC (permalink / raw)
To: musl; +Cc: Christian Brauner
On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
>
> Actually, if there aren't yet archs lacking SYS_clone, this API
> regression may be a good argument not to drop SYS_clone on new archs
> yet until there's a way for new archs to get the same behavior
> (unspecified stack size).
That is a good point, but it also appears that the behavior of
clone3() is unintentional
here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
additional features.
Not sure what the best fix for this is, as the check for size==0 was clearly
intentional, but seems to prevent this from working. A special flag to ignore
the size, or a magic size value like -1ull might work, but neither of them
is a great interface.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-10 10:30 ` Arnd Bergmann
@ 2022-04-10 15:26 ` Rich Felker
2022-04-11 8:03 ` Arnd Bergmann
2022-04-13 7:26 ` Christian Brauner
1 sibling, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-04-10 15:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: musl, Christian Brauner
On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> >
> > Actually, if there aren't yet archs lacking SYS_clone, this API
> > regression may be a good argument not to drop SYS_clone on new archs
> > yet until there's a way for new archs to get the same behavior
> > (unspecified stack size).
>
> That is a good point, but it also appears that the behavior of
> clone3() is unintentional
> here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> additional features.
>
> Not sure what the best fix for this is, as the check for size==0 was clearly
> intentional, but seems to prevent this from working. A special flag to ignore
> the size, or a magic size value like -1ull might work, but neither of them
> is a great interface.
Are there archs already affected, or will this one be the first?
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-10 15:26 ` Rich Felker
@ 2022-04-11 8:03 ` Arnd Bergmann
2022-04-11 12:11 ` Rich Felker
0 siblings, 1 reply; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-11 8:03 UTC (permalink / raw)
To: musl; +Cc: Christian Brauner
On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
>
> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > regression may be a good argument not to drop SYS_clone on new archs
> > > yet until there's a way for new archs to get the same behavior
> > > (unspecified stack size).
> >
> > That is a good point, but it also appears that the behavior of
> > clone3() is unintentional
> > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > additional features.
> >
> > Not sure what the best fix for this is, as the check for size==0 was clearly
> > intentional, but seems to prevent this from working. A special flag to ignore
> > the size, or a magic size value like -1ull might work, but neither of them
> > is a great interface.
>
> Are there archs already affected, or will this one be the first?
We have not added any other architectures since clone3 got added,
so this is the first one.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-11 8:03 ` Arnd Bergmann
@ 2022-04-11 12:11 ` Rich Felker
2022-04-11 13:01 ` Arnd Bergmann
0 siblings, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-04-11 12:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: musl, Christian Brauner
On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
> On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > > >
> > > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > > regression may be a good argument not to drop SYS_clone on new archs
> > > > yet until there's a way for new archs to get the same behavior
> > > > (unspecified stack size).
> > >
> > > That is a good point, but it also appears that the behavior of
> > > clone3() is unintentional
> > > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > > additional features.
> > >
> > > Not sure what the best fix for this is, as the check for size==0 was clearly
> > > intentional, but seems to prevent this from working. A special flag to ignore
> > > the size, or a magic size value like -1ull might work, but neither of them
> > > is a great interface.
> >
> > Are there archs already affected, or will this one be the first?
>
> We have not added any other architectures since clone3 got added,
> so this is the first one.
In that case I really think __NR_clone should just be kept for now. It
doesn't really cost anything on the kernel side and it avoids a
dependency on working out how __NR_clone3 is going to fix the missing
functionality.
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-11 12:11 ` Rich Felker
@ 2022-04-11 13:01 ` Arnd Bergmann
2022-04-12 1:11 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-11 13:01 UTC (permalink / raw)
To: musl; +Cc: Christian Brauner
On Mon, Apr 11, 2022 at 2:11 PM Rich Felker <dalias@libc.org> wrote:
> On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
> > On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > > > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > > > >
> > > > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > > > regression may be a good argument not to drop SYS_clone on new archs
> > > > > yet until there's a way for new archs to get the same behavior
> > > > > (unspecified stack size).
> > > >
> > > > That is a good point, but it also appears that the behavior of
> > > > clone3() is unintentional
> > > > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > > > additional features.
> > > >
> > > > Not sure what the best fix for this is, as the check for size==0 was clearly
> > > > intentional, but seems to prevent this from working. A special flag to ignore
> > > > the size, or a magic size value like -1ull might work, but neither of them
> > > > is a great interface.
> > >
> > > Are there archs already affected, or will this one be the first?
> >
> > We have not added any other architectures since clone3 got added,
> > so this is the first one.
>
> In that case I really think __NR_clone should just be kept for now. It
> doesn't really cost anything on the kernel side and it avoids a
> dependency on working out how __NR_clone3 is going to fix the missing
> functionality.
Yes, fair enough.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-11 13:01 ` Arnd Bergmann
@ 2022-04-12 1:11 ` 王洪亮
2022-04-13 1:16 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-12 1:11 UTC (permalink / raw)
To: musl; +Cc: Christian Brauner
在 2022/4/11 下午9:01, Arnd Bergmann 写道:
> On Mon, Apr 11, 2022 at 2:11 PM Rich Felker <dalias@libc.org> wrote:
>> On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
>>> On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
>>>> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
>>>>> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
>>>>>> Actually, if there aren't yet archs lacking SYS_clone, this API
>>>>>> regression may be a good argument not to drop SYS_clone on new archs
>>>>>> yet until there's a way for new archs to get the same behavior
>>>>>> (unspecified stack size).
>>>>> That is a good point, but it also appears that the behavior of
>>>>> clone3() is unintentional
>>>>> here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
>>>>> additional features.
>>>>>
>>>>> Not sure what the best fix for this is, as the check for size==0 was clearly
>>>>> intentional, but seems to prevent this from working. A special flag to ignore
>>>>> the size, or a magic size value like -1ull might work, but neither of them
>>>>> is a great interface.
>>>> Are there archs already affected, or will this one be the first?
>>> We have not added any other architectures since clone3 got added,
>>> so this is the first one.
>> In that case I really think __NR_clone should just be kept for now. It
>> doesn't really cost anything on the kernel side and it avoids a
>> dependency on working out how __NR_clone3 is going to fix the missing
>> functionality.
> Yes, fair enough.
>
> Arnd
Do I need to implement __clone3 for future called in LoongArch port ?
Hongliang Wang.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-12 1:11 ` 王洪亮
@ 2022-04-13 1:16 ` 王洪亮
0 siblings, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-04-13 1:16 UTC (permalink / raw)
To: musl
在 2022/4/12 上午9:11, 王洪亮 写道:
>
> 在 2022/4/11 下午9:01, Arnd Bergmann 写道:
>> On Mon, Apr 11, 2022 at 2:11 PM Rich Felker <dalias@libc.org> wrote:
>>> On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
>>>> On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
>>>>> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
>>>>>> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
>>>>>>> Actually, if there aren't yet archs lacking SYS_clone, this API
>>>>>>> regression may be a good argument not to drop SYS_clone on new
>>>>>>> archs
>>>>>>> yet until there's a way for new archs to get the same behavior
>>>>>>> (unspecified stack size).
>>>>>> That is a good point, but it also appears that the behavior of
>>>>>> clone3() is unintentional
>>>>>> here, I'm fairly sure it was meant to be a drop-in replacement
>>>>>> for clone() with
>>>>>> additional features.
>>>>>>
>>>>>> Not sure what the best fix for this is, as the check for size==0
>>>>>> was clearly
>>>>>> intentional, but seems to prevent this from working. A special
>>>>>> flag to ignore
>>>>>> the size, or a magic size value like -1ull might work, but
>>>>>> neither of them
>>>>>> is a great interface.
>>>>> Are there archs already affected, or will this one be the first?
>>>> We have not added any other architectures since clone3 got added,
>>>> so this is the first one.
>>> In that case I really think __NR_clone should just be kept for now. It
>>> doesn't really cost anything on the kernel side and it avoids a
>>> dependency on working out how __NR_clone3 is going to fix the missing
>>> functionality.
>> Yes, fair enough.
>>
>> Arnd
>
>
> Do I need to implement __clone3 for future called in LoongArch port ?
>
>
> Hongliang Wang.
Hi,
Have any other issues to modify in LoongArch port ?
Hongliang wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-10 10:30 ` Arnd Bergmann
2022-04-10 15:26 ` Rich Felker
@ 2022-04-13 7:26 ` Christian Brauner
2022-04-13 8:26 ` Arnd Bergmann
1 sibling, 1 reply; 52+ messages in thread
From: Christian Brauner @ 2022-04-13 7:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: musl
On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> >
> > Actually, if there aren't yet archs lacking SYS_clone, this API
> > regression may be a good argument not to drop SYS_clone on new archs
> > yet until there's a way for new archs to get the same behavior
> > (unspecified stack size).
>
> That is a good point, but it also appears that the behavior of
> clone3() is unintentional
> here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> additional features.
Mostly but not in all ways. We did decide it's ok to make API
improvements that might break compatibility with legacy clone().
>
> Not sure what the best fix for this is, as the check for size==0 was clearly
> intentional, but seems to prevent this from working. A special flag to ignore
> the size, or a magic size value like -1ull might work, but neither of them
> is a great interface.
Can someone explain the use-case in a bit more detail, please?
If it is a legitimate use-case that callers need to be able to pass a
stack and have no way of also passing a size then we should just remove
the size == 0 check for all architectures that don't have a hard
requirement on passing a size together with the stack pointer.
Wdyt, Arnd?
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-13 7:26 ` Christian Brauner
@ 2022-04-13 8:26 ` Arnd Bergmann
2022-04-13 9:04 ` Christian Brauner
0 siblings, 1 reply; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-13 8:26 UTC (permalink / raw)
To: Christian Brauner; +Cc: musl
On Wed, Apr 13, 2022 at 9:26 AM Christian Brauner <brauner@kernel.org> wrote:
> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > regression may be a good argument not to drop SYS_clone on new archs
> > > yet until there's a way for new archs to get the same behavior
> > > (unspecified stack size).
> >
> > That is a good point, but it also appears that the behavior of
> > clone3() is unintentional
> > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > additional features.
>
> Mostly but not in all ways. We did decide it's ok to make API
> improvements that might break compatibility with legacy clone().
Ok
> >
> > Not sure what the best fix for this is, as the check for size==0 was clearly
> > intentional, but seems to prevent this from working. A special flag to ignore
> > the size, or a magic size value like -1ull might work, but neither of them
> > is a great interface.
>
> Can someone explain the use-case in a bit more detail, please?
>
> If it is a legitimate use-case that callers need to be able to pass a
> stack and have no way of also passing a size then we should just remove
> the size == 0 check for all architectures that don't have a hard
> requirement on passing a size together with the stack pointer.
>
> Wdyt, Arnd?
The normal rule is that we don't define obsolete system calls in new
architectures when an improved variant has been added, e.g. oldoldstat,
oldstat, stat, newstat and stat64 have all been replaced by statx over
the decades. I was expecting the same to be true for clone(), but if
clone3() is not meant as a replacement, we can keep both around.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-13 8:26 ` Arnd Bergmann
@ 2022-04-13 9:04 ` Christian Brauner
2022-04-13 13:25 ` Arnd Bergmann
0 siblings, 1 reply; 52+ messages in thread
From: Christian Brauner @ 2022-04-13 9:04 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: musl
On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> On Wed, Apr 13, 2022 at 9:26 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > > >
> > > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > > regression may be a good argument not to drop SYS_clone on new archs
> > > > yet until there's a way for new archs to get the same behavior
> > > > (unspecified stack size).
> > >
> > > That is a good point, but it also appears that the behavior of
> > > clone3() is unintentional
> > > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > > additional features.
> >
> > Mostly but not in all ways. We did decide it's ok to make API
> > improvements that might break compatibility with legacy clone().
>
> Ok
>
> > >
> > > Not sure what the best fix for this is, as the check for size==0 was clearly
> > > intentional, but seems to prevent this from working. A special flag to ignore
> > > the size, or a magic size value like -1ull might work, but neither of them
> > > is a great interface.
> >
> > Can someone explain the use-case in a bit more detail, please?
> >
> > If it is a legitimate use-case that callers need to be able to pass a
> > stack and have no way of also passing a size then we should just remove
> > the size == 0 check for all architectures that don't have a hard
> > requirement on passing a size together with the stack pointer.
> >
> > Wdyt, Arnd?
>
> The normal rule is that we don't define obsolete system calls in new
> architectures when an improved variant has been added, e.g. oldoldstat,
> oldstat, stat, newstat and stat64 have all been replaced by statx over
> the decades. I was expecting the same to be true for clone(), but if
> clone3() is not meant as a replacement, we can keep both around.
No, I agree with you on this and would like to only implement clone3()
on new architectures.
What I'm asking is whether removing the size == 0 check is enough to
unblock the missing behavior and whether you'd be on board with removing
the check?
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-13 9:04 ` Christian Brauner
@ 2022-04-13 13:25 ` Arnd Bergmann
2022-04-13 14:09 ` Rich Felker
2022-04-14 9:36 ` Christian Brauner
0 siblings, 2 replies; 52+ messages in thread
From: Arnd Bergmann @ 2022-04-13 13:25 UTC (permalink / raw)
To: Christian Brauner; +Cc: musl
On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> >
> > The normal rule is that we don't define obsolete system calls in new
> > architectures when an improved variant has been added, e.g. oldoldstat,
> > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > the decades. I was expecting the same to be true for clone(), but if
> > clone3() is not meant as a replacement, we can keep both around.
>
> No, I agree with you on this and would like to only implement clone3()
> on new architectures.
>
> What I'm asking is whether removing the size == 0 check is enough to
> unblock the missing behavior and whether you'd be on board with removing
> the check?
I think that's ok here, since we'd only rely on this for loongarch64 at the
moment. It would probably need to be documented in the man page
as a special case though.
Arnd
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-13 13:25 ` Arnd Bergmann
@ 2022-04-13 14:09 ` Rich Felker
2022-04-14 9:36 ` Christian Brauner
2022-04-14 9:36 ` Christian Brauner
1 sibling, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-04-13 14:09 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Christian Brauner, musl
On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > >
> > > The normal rule is that we don't define obsolete system calls in new
> > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > the decades. I was expecting the same to be true for clone(), but if
> > > clone3() is not meant as a replacement, we can keep both around.
> >
> > No, I agree with you on this and would like to only implement clone3()
> > on new architectures.
> >
> > What I'm asking is whether removing the size == 0 check is enough to
> > unblock the missing behavior and whether you'd be on board with removing
> > the check?
>
> I think that's ok here, since we'd only rely on this for loongarch64 at the
> moment. It would probably need to be documented in the man page
> as a special case though.
I'm okay with removing the check for size==0 (so size==0 will be
allowed) and dropping __NR_clone on new archs, as long as it's noted
in comments/documentation that size==0 is explicitly allowed so nobody
breaks this in the future.
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-13 14:09 ` Rich Felker
@ 2022-04-14 9:36 ` Christian Brauner
2022-04-20 9:09 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Christian Brauner @ 2022-04-14 9:36 UTC (permalink / raw)
To: Rich Felker; +Cc: Arnd Bergmann, musl
On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
> On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> > On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > > >
> > > > The normal rule is that we don't define obsolete system calls in new
> > > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > > the decades. I was expecting the same to be true for clone(), but if
> > > > clone3() is not meant as a replacement, we can keep both around.
> > >
> > > No, I agree with you on this and would like to only implement clone3()
> > > on new architectures.
> > >
> > > What I'm asking is whether removing the size == 0 check is enough to
> > > unblock the missing behavior and whether you'd be on board with removing
> > > the check?
> >
> > I think that's ok here, since we'd only rely on this for loongarch64 at the
> > moment. It would probably need to be documented in the man page
> > as a special case though.
>
> I'm okay with removing the check for size==0 (so size==0 will be
> allowed) and dropping __NR_clone on new archs, as long as it's noted
> in comments/documentation that size==0 is explicitly allowed so nobody
> breaks this in the future.
Ok, I'll try to have a patch ready early next week since I'm currently
out sick.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-14 9:36 ` Christian Brauner
@ 2022-04-20 9:09 ` 王洪亮
2022-04-20 13:33 ` Christian Brauner
0 siblings, 1 reply; 52+ messages in thread
From: 王洪亮 @ 2022-04-20 9:09 UTC (permalink / raw)
To: musl, Christian Brauner
在 2022/4/14 下午5:36, Christian Brauner 写道:
> On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
>> On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
>>> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
>>>> On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
>>>>> The normal rule is that we don't define obsolete system calls in new
>>>>> architectures when an improved variant has been added, e.g. oldoldstat,
>>>>> oldstat, stat, newstat and stat64 have all been replaced by statx over
>>>>> the decades. I was expecting the same to be true for clone(), but if
>>>>> clone3() is not meant as a replacement, we can keep both around.
>>>> No, I agree with you on this and would like to only implement clone3()
>>>> on new architectures.
>>>>
>>>> What I'm asking is whether removing the size == 0 check is enough to
>>>> unblock the missing behavior and whether you'd be on board with removing
>>>> the check?
>>> I think that's ok here, since we'd only rely on this for loongarch64 at the
>>> moment. It would probably need to be documented in the man page
>>> as a special case though.
>> I'm okay with removing the check for size==0 (so size==0 will be
>> allowed) and dropping __NR_clone on new archs, as long as it's noted
>> in comments/documentation that size==0 is explicitly allowed so nobody
>> breaks this in the future.
> Ok, I'll try to have a patch ready early next week since I'm currently
> out sick.
Hi,
I'm implementing __NR_clone3 syscall within __clone().
I have another problem:CLONE_DETACHED
in musl,internal call __clone()(such as __pthread_create()),the input
parameter flags
has been set CLONE_DETACHED ,in kernel,there is a check in
clone3_args_valid(),
if the condition met,return false.
How to deal with this problem?
src/thread/pthread_create.c:
int __pthread_create(pthread_t *restrict res, const pthread_attr_t
*restrict attrp,
void *(*entry)(void *), void *restrict arg)
{
unsigned flags = CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND
| CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS
| CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID | CLONE_DETACHED;
...
ret = __clone((c11 ? start_c11 : start), stack, flags, args,
&new->tid,
TP_ADJ(new), &__thread_list_lock);
}
kernel/fork.c:
static bool clone3_args_valid(struct kernel_clone_args *kargs)
{
/*
* - make the CLONE_DETACHED bit reusable for clone3
* - make the CSIGNAL bits reusable for clone3
*/
if (kargs->flags & (CLONE_DETACHED | CSIGNAL))
return false;
}
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-20 9:09 ` 王洪亮
@ 2022-04-20 13:33 ` Christian Brauner
2022-04-20 13:54 ` Rich Felker
0 siblings, 1 reply; 52+ messages in thread
From: Christian Brauner @ 2022-04-20 13:33 UTC (permalink / raw)
To: 王洪亮; +Cc: musl
On Wed, Apr 20, 2022 at 05:09:08PM +0800, 王洪亮 wrote:
>
> 在 2022/4/14 下午5:36, Christian Brauner 写道:
> > On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
> > > On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> > > > On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > > > > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > > > > > The normal rule is that we don't define obsolete system calls in new
> > > > > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > > > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > > > > the decades. I was expecting the same to be true for clone(), but if
> > > > > > clone3() is not meant as a replacement, we can keep both around.
> > > > > No, I agree with you on this and would like to only implement clone3()
> > > > > on new architectures.
> > > > >
> > > > > What I'm asking is whether removing the size == 0 check is enough to
> > > > > unblock the missing behavior and whether you'd be on board with removing
> > > > > the check?
> > > > I think that's ok here, since we'd only rely on this for loongarch64 at the
> > > > moment. It would probably need to be documented in the man page
> > > > as a special case though.
> > > I'm okay with removing the check for size==0 (so size==0 will be
> > > allowed) and dropping __NR_clone on new archs, as long as it's noted
> > > in comments/documentation that size==0 is explicitly allowed so nobody
> > > breaks this in the future.
> > Ok, I'll try to have a patch ready early next week since I'm currently
> > out sick.
>
> Hi,
>
> I'm implementing __NR_clone3 syscall within __clone().
>
> I have another problem:CLONE_DETACHED
>
> in musl,internal call __clone()(such as __pthread_create()),the input
> parameter flags
>
> has been set CLONE_DETACHED ,in kernel,there is a check in
> clone3_args_valid(),
>
> if the condition met,return false.
>
> How to deal with this problem?
CLONE_DETACHED is meaningles since Linux on 2.6.2. There really should
be <=2.6.1 living kernel anywhere where CLONE_DETACHED does anything.
I've documented that in detail under [1] as:
CLONE_DETACHED (historical)
For a while (during the Linux 2.5 development series)
there was a CLONE_DETACHED flag, which caused the parent
not to receive a signal when the child terminated.
Ultimately, the effect of this flag was subsumed under the
CLONE_THREAD flag and by the time Linux 2.6.0 was
released, this flag had no effect. Starting in Linux
2.6.2, the need to give this flag together with
CLONE_THREAD disappeared.
This flag is still defined, but it is usually ignored when
calling clone(). However, see the description of
CLONE_PIDFD for some exceptions.
[1]: https://man7.org/linux/man-pages/man2/clone.2.html
Would it be possible to drop this flag from musl's pthread_create()
implementation? (Iirc, glibc dropped CLONE_DETACHED in 2004.)
>
> src/thread/pthread_create.c:
> int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict
> attrp,
> void *(*entry)(void *), void *restrict arg)
> {
> unsigned flags = CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND
> | CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS
> | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID | CLONE_DETACHED;
> ...
> ret = __clone((c11 ? start_c11 : start), stack, flags, args, &new->tid,
> TP_ADJ(new), &__thread_list_lock);
> }
>
> kernel/fork.c:
> static bool clone3_args_valid(struct kernel_clone_args *kargs)
> {
> /*
> * - make the CLONE_DETACHED bit reusable for clone3
> * - make the CSIGNAL bits reusable for clone3
> */
> if (kargs->flags & (CLONE_DETACHED | CSIGNAL))
> return false;
> }
>
>
> Hongliang Wang
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-20 13:33 ` Christian Brauner
@ 2022-04-20 13:54 ` Rich Felker
2022-04-21 6:54 ` 王洪亮
0 siblings, 1 reply; 52+ messages in thread
From: Rich Felker @ 2022-04-20 13:54 UTC (permalink / raw)
To: Christian Brauner; +Cc: 王洪亮, musl
On Wed, Apr 20, 2022 at 03:33:25PM +0200, Christian Brauner wrote:
> On Wed, Apr 20, 2022 at 05:09:08PM +0800, 王洪亮 wrote:
> >
> > 在 2022/4/14 下午5:36, Christian Brauner 写道:
> > > On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
> > > > On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> > > > > On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > > > > > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > > > > > > The normal rule is that we don't define obsolete system calls in new
> > > > > > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > > > > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > > > > > the decades. I was expecting the same to be true for clone(), but if
> > > > > > > clone3() is not meant as a replacement, we can keep both around.
> > > > > > No, I agree with you on this and would like to only implement clone3()
> > > > > > on new architectures.
> > > > > >
> > > > > > What I'm asking is whether removing the size == 0 check is enough to
> > > > > > unblock the missing behavior and whether you'd be on board with removing
> > > > > > the check?
> > > > > I think that's ok here, since we'd only rely on this for loongarch64 at the
> > > > > moment. It would probably need to be documented in the man page
> > > > > as a special case though.
> > > > I'm okay with removing the check for size==0 (so size==0 will be
> > > > allowed) and dropping __NR_clone on new archs, as long as it's noted
> > > > in comments/documentation that size==0 is explicitly allowed so nobody
> > > > breaks this in the future.
> > > Ok, I'll try to have a patch ready early next week since I'm currently
> > > out sick.
> >
> > Hi,
> >
> > I'm implementing __NR_clone3 syscall within __clone().
> >
> > I have another problem:CLONE_DETACHED
> >
> > in musl,internal call __clone()(such as __pthread_create()),the input
> > parameter flags
> >
> > has been set CLONE_DETACHED ,in kernel,there is a check in
> > clone3_args_valid(),
> >
> > if the condition met,return false.
> >
> > How to deal with this problem?
>
> CLONE_DETACHED is meaningles since Linux on 2.6.2. There really should
> be <=2.6.1 living kernel anywhere where CLONE_DETACHED does anything.
> I've documented that in detail under [1] as:
>
> CLONE_DETACHED (historical)
> For a while (during the Linux 2.5 development series)
> there was a CLONE_DETACHED flag, which caused the parent
> not to receive a signal when the child terminated.
> Ultimately, the effect of this flag was subsumed under the
> CLONE_THREAD flag and by the time Linux 2.6.0 was
> released, this flag had no effect. Starting in Linux
> 2.6.2, the need to give this flag together with
> CLONE_THREAD disappeared.
>
> This flag is still defined, but it is usually ignored when
> calling clone(). However, see the description of
> CLONE_PIDFD for some exceptions.
>
> [1]: https://man7.org/linux/man-pages/man2/clone.2.html
>
> Would it be possible to drop this flag from musl's pthread_create()
> implementation? (Iirc, glibc dropped CLONE_DETACHED in 2004.)
I think __clone should just mask it on newer archs. We support Linux
2.6.0 and if lack of CLONE_DETACHED causes bogus signals on 2.6.0 we
should keep it. If it can be established that this doesn't happen and
that CLONE_DETACHED just affected non-thread clones, we can probably
safely drop it.
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-20 13:54 ` Rich Felker
@ 2022-04-21 6:54 ` 王洪亮
0 siblings, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-04-21 6:54 UTC (permalink / raw)
To: musl; +Cc: Christian Brauner
在 2022/4/20 下午9:54, Rich Felker 写道
>>> Hi,
>>>
>>> I'm implementing __NR_clone3 syscall within __clone().
>>>
>>> I have another problem:CLONE_DETACHED
>>>
>>> in musl,internal call __clone()(such as __pthread_create()),the input
>>> parameter flags
>>>
>>> has been set CLONE_DETACHED ,in kernel,there is a check in
>>> clone3_args_valid(),
>>>
>>> if the condition met,return false.
>>>
>>> How to deal with this problem?
>> CLONE_DETACHED is meaningles since Linux on 2.6.2. There really should
>> be <=2.6.1 living kernel anywhere where CLONE_DETACHED does anything.
>> I've documented that in detail under [1] as:
>>
>> CLONE_DETACHED (historical)
>> For a while (during the Linux 2.5 development series)
>> there was a CLONE_DETACHED flag, which caused the parent
>> not to receive a signal when the child terminated.
>> Ultimately, the effect of this flag was subsumed under the
>> CLONE_THREAD flag and by the time Linux 2.6.0 was
>> released, this flag had no effect. Starting in Linux
>> 2.6.2, the need to give this flag together with
>> CLONE_THREAD disappeared.
>>
>> This flag is still defined, but it is usually ignored when
>> calling clone(). However, see the description of
>> CLONE_PIDFD for some exceptions.
>>
>> [1]: https://man7.org/linux/man-pages/man2/clone.2.html
>>
>> Would it be possible to drop this flag from musl's pthread_create()
>> implementation? (Iirc, glibc dropped CLONE_DETACHED in 2004.)
> I think __clone should just mask it on newer archs. We support Linux
> 2.6.0 and if lack of CLONE_DETACHED causes bogus signals on 2.6.0 we
> should keep it. If it can be established that this doesn't happen and
> that CLONE_DETACHED just affected non-thread clones, we can probably
> safely drop it.
>
> Rich
I have already implemented __NR_clone3 syscall within __clone(),
and libc-test OK.the code is shown below,please help review.
src/thread/loongarch64/clone.s:
#__clone(func, stack, flags, arg, ptid, tls, ctid)
# a0, a1, a2, a3, a4, a5, a6
# sys_clone3(struct clone_args *cl_args, size_t size)
# a0 a1
.global __clone
.hidden __clone
.type __clone,@function
__clone:
# Save function pointer and argument pointer on new thread stack
addi.d $a1, $a1, -16
st.d $a0, $a1, 0 # save function pointer
st.d $a3, $a1, 8 # save argument pointer
li.d $t0, ~0x004000ff # mask CSIGNAL and CLONE_DETACHED
and $t1, $a2, $t0 # cl_args.flags
li.d $t0, 0x000000ff # CSIGNAL
and $t2, $a2, $t0 # cl_args.exit_signal
bstrins.d $sp, $zero, 2, 0 # align stack to 8 bytes
addi.d $sp, $sp, -88 # struct clone_args
st.d $t1, $sp, 0 # flags
st.d $a4, $sp, 8 # pidfd
st.d $a6, $sp, 16 # child_tid
st.d $a4, $sp, 24 # parent_tid
st.d $t2, $sp, 32 # exit_signal
st.d $a1, $sp, 40 # stack
st.d $zero, $sp, 48 # stack_size
st.d $a5, $sp, 56 # tls
st.d $zero, $sp, 64 # set_tid
st.d $zero, $sp, 72 # set_tid_size
st.d $zero, $sp, 80 # cgroup
move $a0, $sp
li.d $a1, 88
li.d $a7, 435 # __NR_clone3
syscall 0 # call clone3
beqz $a0, 1f # whether child process
addi.d $sp, $sp, 88
jirl $zero, $ra, 0 # parent process return
1:
ld.d $t8, $sp, 0 # function pointer
ld.d $a0, $sp, 8 # argument pointer
jirl $ra, $t8, 0 # call the user's function
li.d $a7, 93
syscall 0 # child process exit
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-13 13:25 ` Arnd Bergmann
2022-04-13 14:09 ` Rich Felker
@ 2022-04-14 9:36 ` Christian Brauner
1 sibling, 0 replies; 52+ messages in thread
From: Christian Brauner @ 2022-04-14 9:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: musl
On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > >
> > > The normal rule is that we don't define obsolete system calls in new
> > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > the decades. I was expecting the same to be true for clone(), but if
> > > clone3() is not meant as a replacement, we can keep both around.
> >
> > No, I agree with you on this and would like to only implement clone3()
> > on new architectures.
> >
> > What I'm asking is whether removing the size == 0 check is enough to
> > unblock the missing behavior and whether you'd be on board with removing
> > the check?
>
> I think that's ok here, since we'd only rely on this for loongarch64 at the
> moment. It would probably need to be documented in the man page
> as a special case though.
Ok, I'll try to have a patch ready early next week since I'm currently
out sick.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-09 13:19 ` Rich Felker
2022-04-09 13:30 ` Rich Felker
@ 2022-04-13 7:19 ` Christian Brauner
2022-04-13 14:06 ` Rich Felker
1 sibling, 1 reply; 52+ messages in thread
From: Christian Brauner @ 2022-04-13 7:19 UTC (permalink / raw)
To: Rich Felker; +Cc: Arnd Bergmann, musl
On Sat, Apr 09, 2022 at 09:19:39AM -0400, Rich Felker wrote:
> On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
> > > >
> > > > What happens in the clone() syscall in the kernel is that the size
> > > > gets added to the initial pointer on normal architectures (parisc and ia64
> > > > being the exceptions). If you already have the stack pointer, I think you can
> > > > just pass size=0 as we do internally in the kernel.
> > > >
> > > > If there was a port of musl to one of the architectures that does it
> > > > differently,
> > > > then changing callers such as
> > > >
> > > > pid = __clone(child, stack+sizeof stack,
> > > > CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
> > > >
> > > > would be required, and the separate size argument in clone3() could
> > > > help keep that hidden from musl.
> > > >
> > > > Arnd
> > >
> > >
> > > In LoongArch,the stack is grows down.
> > >
> > > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > > in loongarch port,based on __clone() interface unchanged and the
> > > architecture-independent code of call __clone() unchanged.
> > >
> > > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > > must not be 0)
> > > if (kargs->stack_size == 0)
> > > return false;
> > >
> > > current,the __clone()'s input parameters have no "stack_size",so I can't
> > > pass valid(must be size!=0) stack_size to clone3.
> > >
> > > your meaning is pass stack_size=0 when the input parameter "stack" of
> > > __clone()
> > > is already stack point? but pass stack_size=0 is illegal.
> >
> > Ah, you are right, that doesn't work at the moment. You dropped Christian
> > from the Cc list, adding him back because he probably has an idea
> > for how to address that.
> >
> > It looks like it could be fixed for the internal callers of __clone() by
> > adding a __clone3() call that takes the size argument, and falls back
> > to calling __clone() on architectures that have that. I don't see how
> > one would do it for the generic clone() library function call though.
>
> size=4k and passing stack-4k? O_o
>
> This seems like a ridiculous kernel regression to require a size when
> none may be available...
Hm, clone3() is a separate system call. The aim had never been to
provide 1:1 compatibility with legacy clone(). So I fail to see how this
is a regression.
(I'd appreciate if we could stay away from unnecessary qualifiers like
"ridiculous". That doesn't really help the thread in any way.)
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-13 7:19 ` Christian Brauner
@ 2022-04-13 14:06 ` Rich Felker
0 siblings, 0 replies; 52+ messages in thread
From: Rich Felker @ 2022-04-13 14:06 UTC (permalink / raw)
To: Christian Brauner; +Cc: Arnd Bergmann, musl
On Wed, Apr 13, 2022 at 09:19:11AM +0200, Christian Brauner wrote:
> On Sat, Apr 09, 2022 at 09:19:39AM -0400, Rich Felker wrote:
> > On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> > > On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
> > > > >
> > > > > What happens in the clone() syscall in the kernel is that the size
> > > > > gets added to the initial pointer on normal architectures (parisc and ia64
> > > > > being the exceptions). If you already have the stack pointer, I think you can
> > > > > just pass size=0 as we do internally in the kernel.
> > > > >
> > > > > If there was a port of musl to one of the architectures that does it
> > > > > differently,
> > > > > then changing callers such as
> > > > >
> > > > > pid = __clone(child, stack+sizeof stack,
> > > > > CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
> > > > >
> > > > > would be required, and the separate size argument in clone3() could
> > > > > help keep that hidden from musl.
> > > > >
> > > > > Arnd
> > > >
> > > >
> > > > In LoongArch,the stack is grows down.
> > > >
> > > > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > > > in loongarch port,based on __clone() interface unchanged and the
> > > > architecture-independent code of call __clone() unchanged.
> > > >
> > > > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > > > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > > > must not be 0)
> > > > if (kargs->stack_size == 0)
> > > > return false;
> > > >
> > > > current,the __clone()'s input parameters have no "stack_size",so I can't
> > > > pass valid(must be size!=0) stack_size to clone3.
> > > >
> > > > your meaning is pass stack_size=0 when the input parameter "stack" of
> > > > __clone()
> > > > is already stack point? but pass stack_size=0 is illegal.
> > >
> > > Ah, you are right, that doesn't work at the moment. You dropped Christian
> > > from the Cc list, adding him back because he probably has an idea
> > > for how to address that.
> > >
> > > It looks like it could be fixed for the internal callers of __clone() by
> > > adding a __clone3() call that takes the size argument, and falls back
> > > to calling __clone() on architectures that have that. I don't see how
> > > one would do it for the generic clone() library function call though.
> >
> > size=4k and passing stack-4k? O_o
> >
> > This seems like a ridiculous kernel regression to require a size when
> > none may be available...
>
> Hm, clone3() is a separate system call. The aim had never been to
> provide 1:1 compatibility with legacy clone(). So I fail to see how this
> is a regression.
It's only a regression if __NR_clone3 is expected to provide a
replacement for __NR_clone where new archs will drop __NR_clone. If
both syscalls will continue to exist then I agree it's not a
regression.
> (I'd appreciate if we could stay away from unnecessary qualifiers like
> "ridiculous". That doesn't really help the thread in any way.)
Fair.
Rich
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [musl] Re: add loongarch64 port
2022-04-09 11:06 ` Arnd Bergmann
2022-04-09 13:19 ` Rich Felker
@ 2022-04-11 3:40 ` 王洪亮
1 sibling, 0 replies; 52+ messages in thread
From: 王洪亮 @ 2022-04-11 3:40 UTC (permalink / raw)
To: musl; +Cc: Christian Brauner
在 2022/4/9 下午7:06, Arnd Bergmann 写道:
> On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
>>> On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
>>>
>>> What happens in the clone() syscall in the kernel is that the size
>>> gets added to the initial pointer on normal architectures (parisc and ia64
>>> being the exceptions). If you already have the stack pointer, I think you can
>>> just pass size=0 as we do internally in the kernel.
>>>
>>> If there was a port of musl to one of the architectures that does it
>>> differently,
>>> then changing callers such as
>>>
>>> pid = __clone(child, stack+sizeof stack,
>>> CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
>>>
>>> would be required, and the separate size argument in clone3() could
>>> help keep that hidden from musl.
>>>
>>> Arnd
>>
>> In LoongArch,the stack is grows down.
>>
>> As previous suggested,I implement __NR_clone3 syscall within __clone()
>> in loongarch port,based on __clone() interface unchanged and the
>> architecture-independent code of call __clone() unchanged.
>>
>> In __NR_clone3 syscall,I need pass the lowest address of memory area to
>> clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
>> must not be 0)
>> if (kargs->stack_size == 0)
>> return false;
>>
>> current,the __clone()'s input parameters have no "stack_size",so I can't
>> pass valid(must be size!=0) stack_size to clone3.
>>
>> your meaning is pass stack_size=0 when the input parameter "stack" of
>> __clone()
>> is already stack point? but pass stack_size=0 is illegal.
> Ah, you are right, that doesn't work at the moment. You dropped Christian
> from the Cc list, adding him back because he probably has an idea
> for how to address that.
>
> It looks like it could be fixed for the internal callers of __clone() by
> adding a __clone3() call that takes the size argument, and falls back
> to calling __clone() on architectures that have that. I don't see how
> one would do it for the generic clone() library function call though.
>
> Arnd
from Christian Brauner's patch in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
In clone3,the difference is move stack point's setup from userspace to
kernelspace.
userspace is only responsible for alloc memory area and pass the base
address of
memory area,kernel is responsible for setup stack point according to the
direction
the stack's grow.in other words,there is no longer the concept of stack
in userspace.
so clone3 is incompatible with clone.__NR_clone could not be removed
from kernel easily,
otherwise the existing user application call clone() is not work.
I understand the case is:
1.In kernel,__NR_clone and __NR_clone3 both support,at least for some time;
2.In libc,__clone() and __clone3() both implement(internal call,glibc
implement the convert),
clone() and clone3() both export for user.
3.existing application call clone() could work well, new application
could select to call
clone3().
Hongliang Wang
^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2022-04-27 2:13 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-22 3:52 [musl] add loongarch64 port 王洪亮
2022-03-22 12:59 ` Rich Felker
2022-03-22 15:06 ` Jeffrey Walton
2022-03-22 16:04 ` Rich Felker
2022-03-24 3:01 ` 王洪亮
2022-03-24 2:22 ` 王洪亮
2022-03-22 19:03 ` Rich Felker
2022-03-22 20:36 ` Arnd Bergmann
2022-03-24 1:53 ` 王洪亮
2022-03-24 1:35 ` 王洪亮
2022-03-29 8:12 ` [musl] " 王洪亮
2022-03-29 8:26 ` Arnd Bergmann
2022-03-31 6:20 王洪亮
2022-03-31 8:14 ` Arnd Bergmann
2022-04-01 7:40 ` 王洪亮
2022-04-01 7:48 ` Arnd Bergmann
2022-04-02 6:19 ` 王洪亮
2022-04-02 7:21 ` Rich Felker
2022-04-02 9:53 ` 王洪亮
2022-04-27 1:58 ` 王洪亮
2022-04-27 2:13 ` Rich Felker
2022-03-31 18:47 ` Rich Felker
2022-04-02 7:59 ` 王洪亮
2022-04-06 2:08 ` 王洪亮
2022-04-06 16:00 ` Markus Wichmann
2022-04-08 2:21 ` 王洪亮
2022-04-08 6:46 ` Arnd Bergmann
2022-04-09 3:54 ` 王洪亮
2022-04-09 11:06 ` Arnd Bergmann
2022-04-09 13:19 ` Rich Felker
2022-04-09 13:30 ` Rich Felker
2022-04-10 10:30 ` Arnd Bergmann
2022-04-10 15:26 ` Rich Felker
2022-04-11 8:03 ` Arnd Bergmann
2022-04-11 12:11 ` Rich Felker
2022-04-11 13:01 ` Arnd Bergmann
2022-04-12 1:11 ` 王洪亮
2022-04-13 1:16 ` 王洪亮
2022-04-13 7:26 ` Christian Brauner
2022-04-13 8:26 ` Arnd Bergmann
2022-04-13 9:04 ` Christian Brauner
2022-04-13 13:25 ` Arnd Bergmann
2022-04-13 14:09 ` Rich Felker
2022-04-14 9:36 ` Christian Brauner
2022-04-20 9:09 ` 王洪亮
2022-04-20 13:33 ` Christian Brauner
2022-04-20 13:54 ` Rich Felker
2022-04-21 6:54 ` 王洪亮
2022-04-14 9:36 ` Christian Brauner
2022-04-13 7:19 ` Christian Brauner
2022-04-13 14:06 ` Rich Felker
2022-04-11 3:40 ` 王洪亮
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).