mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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  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 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

* 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 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 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

* [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-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  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-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-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  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-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-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-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-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  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-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  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  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-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-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-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-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-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  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-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-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

* 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-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-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 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  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-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-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-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-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-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-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 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  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-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-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-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-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  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  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

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).