mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Add SYSCALL_USE_SOCKETCALL for old arch
@ 2020-08-03  7:41 David Timber
  2020-08-03 13:33 ` Rich Felker
  0 siblings, 1 reply; 6+ messages in thread
From: David Timber @ 2020-08-03  7:41 UTC (permalink / raw)
  To: musl

The following arches do not have __NR_SOCKET in kernel version 2.4.x,
but musl makes call to socket(), resulting in ENOSYS:

* arm
* powerpc
* powerpc64
* sh (32bit only)

Adding `#define SYSCALL_USE_SOCKETCALL` would solve the problem, but
doing so will incur a bit of overhead. uClibc checks if `__NR_socket`
is defined. I suggest you do the same.

https://git.uclibc.org/uClibc/tree/libc/inet/socketcalls.c#n387

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] Add SYSCALL_USE_SOCKETCALL for old arch
  2020-08-03  7:41 [musl] Add SYSCALL_USE_SOCKETCALL for old arch David Timber
@ 2020-08-03 13:33 ` Rich Felker
       [not found]   ` <CAGYH49BV-SG0THP2kzbSVVRypkk0APF1MQb74geskos=dDLv6A@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2020-08-03 13:33 UTC (permalink / raw)
  To: David Timber; +Cc: musl

On Mon, Aug 03, 2020 at 05:11:59PM +0930, David Timber wrote:
> The following arches do not have __NR_SOCKET in kernel version 2.4.x,
> but musl makes call to socket(), resulting in ENOSYS:
> 
> * arm
> * powerpc
> * powerpc64
> * sh (32bit only)

The minimum supported kernel version is 2.6.0; anything earlier is on
an as-it-happens-to-work basis. In particular threads and a good deal
of related functionality will not work at all on 2.4, and on arm
nothing at all works on 2.4 because the initial __ARM_NR_set_tls
syscall fails with ENOSYS. The others however should work minimally
since the thread pointer is kept in a userspace-accessible register.
Which arch(s) are you trying where you get far enough to try to open a
socket?

> Adding `#define SYSCALL_USE_SOCKETCALL` would solve the problem, but
> doing so will incur a bit of overhead. uClibc checks if `__NR_socket`
> is defined. I suggest you do the same.
> 
> https://git.uclibc.org/uClibc/tree/libc/inet/socketcalls.c#n387

This does not work since __NR_socket is always defined. I suppose
uClibc does some thing where you're expected to compile with kernel
headers from the kernel you intend to run with and things subtly break
if they mismatch; musl does not do this and does not use kernel
headers at all. This is a runtime issue that can't be decided at
compiletime.

Since 2.4 is not actually supported, I don't want to do anything that
increases complexity here for its sake. However, there have been
requests to use recently-added SYS_socket, etc. for archs that
previously used SYS_socketcall because the new ones are friendlier to
seccomp filtering. The right resolution to the problem you're seeing
is probably switching to always using the new syscalls first if
they're available, only falling back to SYS_socketcall if they fail
with ENOSYS (and only on archs where SYS_socketcall exists to begin
with), and getting rid of the SYSCALL_USE_SOCKETCALL macro entirely
since we'll be treating all archs the same.

Does this sound reasonable?

Rich

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] Add SYSCALL_USE_SOCKETCALL for old arch
       [not found]         ` <CAGYH49AEpS9_ndXP=x20Qpj7tx0RBEyt+iB5nEjD4odUW02wiQ@mail.gmail.com>
@ 2020-08-04 18:18           ` Rich Felker
  2020-08-04 18:56             ` Markus Wichmann
  0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2020-08-04 18:18 UTC (permalink / raw)
  To: David Timber, musl

On Tue, Aug 04, 2020 at 12:44:41PM +0930, David Timber wrote:
> Yes, I can confirm. Attached are the qemu machines for testing(they're
> 2.6.35.9 kernel). The BusyBox cannot set up network interfaces because
> it calls socket() to interface with Netlink. "Function not
> implemented" messages appear after init.

Indeed it looks like, at least on powerpc, the separate syscalls were
added in 2.6.36. So unless there's some other reason earlier kernel
versions were unusable on powerpc (note: on ARM 2.6.15 and earlier
are unusable with musl since they didn't yet have EABI, the ABI we
use, and EABI has always had the separate socket syscalls) I think
this is a genuine bug. Likewise for sh.

> On the 2.6.0 source tree, run:
> ```
> for f in include/asm-*/unistd*.h
> do
>    echo "$f"; cat "$f" | grep __NR_socket
> done
> ```
> 
> Look for the ones without __NR_socket. Looks like there's more than 3...
> 
> The output:
> include/asm-alpha/unistd.h
> #define __NR_socket 97
> #define __NR_socketpair 135
> include/asm-arm26/unistd.h
> #define __NR_socketcall (__NR_SYSCALL_BASE+102)
> include/asm-arm/unistd.h
> #define __NR_socketcall (__NR_SYSCALL_BASE+102)
> include/asm-cris/unistd.h
> #define __NR_socketcall 102
> include/asm-h8300/unistd.h
> #define __NR_socketcall 102
> include/asm-i386/unistd.h
> #define __NR_socketcall 102
> include/asm-ia64/unistd.h
> #define __NR_socket 1190
> #define __NR_socketpair 1197
> include/asm-m68knommu/unistd.h
> #define __NR_socketcall 102
> include/asm-m68k/unistd.h
> #define __NR_socketcall 102
> include/asm-mips/unistd.h
> #define __NR_socketcall (__NR_Linux + 102)
> #define __NR_socket (__NR_Linux + 183)
> #define __NR_socketpair (__NR_Linux + 184)
> #define __NR_socket (__NR_Linux +  40)
> #define __NR_socketpair (__NR_Linux +  52)
> #define __NR_socket (__NR_Linux +  40)
> #define __NR_socketpair (__NR_Linux +  52)
> include/asm-parisc/unistd.h
> #define __NR_socket              (__NR_Linux + 17)
> #define __NR_socketpair          (__NR_Linux + 56)
> /* #define __NR_socketcall         (__NR_Linux + 102) */
> include/asm-ppc64/unistd.h
> #define __NR_socketcall 102
> include/asm-ppc/unistd.h
> #define __NR_socketcall 102
> include/asm-s390/unistd.h
> #define __NR_socketcall         102
> include/asm-sh/unistd.h
> #define __NR_socketcall 102
> include/asm-sparc64/unistd.h
> #define __NR_socket              97 /* Common
>             */
> #define __NR_socketpair         135 /* Common
>             */
> #define __NR_socketcall         206 /* Linux Specific
>             */
> include/asm-sparc/unistd.h
> #define __NR_socket              97 /* Common
>             */
> #define __NR_socketpair         135 /* Common
>             */
> #define __NR_socketcall         206 /* Linux Specific
>             */
> include/asm-um/unistd.h
> include/asm-v850/unistd.h
> #define __NR_socketcall 102
> include/asm-x86_64/unistd.h
> #define __NR_socket                             41
> __SYSCALL(__NR_socket, sys_socket)
> #define __NR_socketpair                         53
> __SYSCALL(__NR_socketpair, sys_socketpair)

Of these, only ppc, ppc64, sh, and possibly s390 (we only support
64-bit "s390x" and I'm not sure if it ever lacked the broken-down
syscalls) are relevant. The rest are either unsupported by musl
(including pre-EABI arm) or already using SYS_socketcall.




> On Mon, 3 Aug 2020 at 23:45, Rich Felker <dalias@libc.org> wrote:
> >
> > On Mon, Aug 03, 2020 at 11:40:25PM +0930, David Timber wrote:
> > > And it does seem reasonable to me, but it'll mean that using no macro
> > > at all and adding a few more bytes to the binary if you're getting rid
> > > of SYSCALL_USE_SOCKETCALL. Quite tricky to support everything without
> > > kenel headers, huh. Maybe fallback to socketcall() for those 2 arch
> > > only. But if you don't want complexity, I don't know. Your project,
> > > your rules.
> >
> > If we're going to use the new syscalls on additional archs (including
> > for example i386) which has been requested due to seccomp, then the
> > fallback is needed for all of them as well.
> >
> > > On Mon, 3 Aug 2020 at 23:31, David Timber <mieabby@gmail.com> wrote:
> > > >
> > > > I didn't know that musl does not include any kernel headers. You're
> > > > right. Checking __NR_socket wouldn't work in this case. That explains
> > > > why there's syscall.h in each arch.
> > > >
> > > > Still, I ran BusyBox(musl linked) on PowerPC and SH4 machine with
> > > > 2.6.x kernel and they still couldn't use socket() at all. If you look
> > > > at the kernel source code, you'll see that the socket syscall is not
> > > > defined for those arch.
> >
> > Your original email said 2.4. If the syscalls we're using are missing
> > in 2.6 then this is a bug in musl that should be fixed. Can you
> > confirm that this is the case?
> >
> > > > No worries at all. I just switched back to uClibc. Musl looked
> > > > attractive because it produces a bit smaller binaries than uClibc. I
> > > > don't wanna encounter any more bugs like this further down the road.
> > > > No offence.
> > > >
> > > > Thanks.
> > > >
> > > > On Mon, 3 Aug 2020 at 23:03, Rich Felker <dalias@libc.org> wrote:
> > > > >
> > > > > On Mon, Aug 03, 2020 at 05:11:59PM +0930, David Timber wrote:
> > > > > > The following arches do not have __NR_SOCKET in kernel version 2.4.x,
> > > > > > but musl makes call to socket(), resulting in ENOSYS:
> > > > > >
> > > > > > * arm
> > > > > > * powerpc
> > > > > > * powerpc64
> > > > > > * sh (32bit only)
> > > > >
> > > > > The minimum supported kernel version is 2.6.0; anything earlier is on
> > > > > an as-it-happens-to-work basis. In particular threads and a good deal
> > > > > of related functionality will not work at all on 2.4, and on arm
> > > > > nothing at all works on 2.4 because the initial __ARM_NR_set_tls
> > > > > syscall fails with ENOSYS. The others however should work minimally
> > > > > since the thread pointer is kept in a userspace-accessible register.
> > > > > Which arch(s) are you trying where you get far enough to try to open a
> > > > > socket?
> > > > >
> > > > > > Adding `#define SYSCALL_USE_SOCKETCALL` would solve the problem, but
> > > > > > doing so will incur a bit of overhead. uClibc checks if `__NR_socket`
> > > > > > is defined. I suggest you do the same.
> > > > > >
> > > > > > https://git.uclibc.org/uClibc/tree/libc/inet/socketcalls.c#n387
> > > > >
> > > > > This does not work since __NR_socket is always defined. I suppose
> > > > > uClibc does some thing where you're expected to compile with kernel
> > > > > headers from the kernel you intend to run with and things subtly break
> > > > > if they mismatch; musl does not do this and does not use kernel
> > > > > headers at all. This is a runtime issue that can't be decided at
> > > > > compiletime.
> > > > >
> > > > > Since 2.4 is not actually supported, I don't want to do anything that
> > > > > increases complexity here for its sake. However, there have been
> > > > > requests to use recently-added SYS_socket, etc. for archs that
> > > > > previously used SYS_socketcall because the new ones are friendlier to
> > > > > seccomp filtering. The right resolution to the problem you're seeing
> > > > > is probably switching to always using the new syscalls first if
> > > > > they're available, only falling back to SYS_socketcall if they fail
> > > > > with ENOSYS (and only on archs where SYS_socketcall exists to begin
> > > > > with), and getting rid of the SYSCALL_USE_SOCKETCALL macro entirely
> > > > > since we'll be treating all archs the same.
> > > > >
> > > > > Does this sound reasonable?
> > > > >
> > > > > Rich




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] Add SYSCALL_USE_SOCKETCALL for old arch
  2020-08-04 18:18           ` Rich Felker
@ 2020-08-04 18:56             ` Markus Wichmann
  2020-08-04 19:15               ` Rich Felker
  0 siblings, 1 reply; 6+ messages in thread
From: Markus Wichmann @ 2020-08-04 18:56 UTC (permalink / raw)
  To: musl

On Tue, Aug 04, 2020 at 02:18:45PM -0400, Rich Felker wrote:
> Of these, only ppc, ppc64, sh, and possibly s390 (we only support
> 64-bit "s390x" and I'm not sure if it ever lacked the broken-down
> syscalls) are relevant. The rest are either unsupported by musl
> (including pre-EABI arm) or already using SYS_socketcall.

According to musl source, all currently supported architectures have
__NR_socket (I didn't check the other calls; I just assumed that
__NR_socket was a stand-in for all the other ones).

Therefore the required change can be performed by changing the
__socketcall macro (and __socketcall_cp of course). Something like this,
maybe? (If using GCC statement expressions is alright):

#ifdef __NR_socketcall
#define __socketcall(nm, a, b, c, d, e, f) \
    ({int r = __syscall(__NR_ ## nm, a, b, c, d, e, f); \
    if (r == -ENOSYS) \
        r = __syscall(__NR_socketcall, __SC_ ## nm, \
            (long[6]){(long)a, (long) b, (long)c, (long)d, (long)e, (long) f});
    r;})
#else
#define __socketcall(nm, a, b, c, d, e, f) __syscall(__NR_ ## nm, a, b, c, d, e, f)
#endif

Ciao,
Markus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] Add SYSCALL_USE_SOCKETCALL for old arch
  2020-08-04 18:56             ` Markus Wichmann
@ 2020-08-04 19:15               ` Rich Felker
  2020-08-06  2:18                 ` [musl] [PATCH] use new socket syscalls, fallback to socketcall Rich Felker
  0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2020-08-04 19:15 UTC (permalink / raw)
  To: musl

On Tue, Aug 04, 2020 at 08:56:42PM +0200, Markus Wichmann wrote:
> On Tue, Aug 04, 2020 at 02:18:45PM -0400, Rich Felker wrote:
> > Of these, only ppc, ppc64, sh, and possibly s390 (we only support
> > 64-bit "s390x" and I'm not sure if it ever lacked the broken-down
> > syscalls) are relevant. The rest are either unsupported by musl
> > (including pre-EABI arm) or already using SYS_socketcall.
> 
> According to musl source, all currently supported architectures have
> __NR_socket (I didn't check the other calls; I just assumed that
> __NR_socket was a stand-in for all the other ones).
> 
> Therefore the required change can be performed by changing the
> __socketcall macro (and __socketcall_cp of course). Something like this,
> maybe? (If using GCC statement expressions is alright):
> 
> #ifdef __NR_socketcall
> #define __socketcall(nm, a, b, c, d, e, f) \
>     ({int r = __syscall(__NR_ ## nm, a, b, c, d, e, f); \
>     if (r == -ENOSYS) \
>         r = __syscall(__NR_socketcall, __SC_ ## nm, \
>             (long[6]){(long)a, (long) b, (long)c, (long)d, (long)e, (long) f});
>     r;})
> #else
> #define __socketcall(nm, a, b, c, d, e, f) __syscall(__NR_ ## nm, a, b, c, d, e, f)
> #endif

This would work, but we don't use statement-expressions in musl. I
think an alternative with an inline function would be trivial, though:

static inline long __socketcall(int sys, int sock, long a, long b, long c, long d, long e, long f)
{
	long r = __syscall(sys, a, b, c, d, e, f);
	if (r != -ENOSYS) return r;
	return __syscall(SYS_socketcall, sock, ((long[6]){a, b, c, d, e, f}));
}
#define __socketcall(nm, a, b, c, d, e, f) __socketcall(SYS_##nm, __SC_##nm, \
	(long)(a), (long)(b), (long)(c), (long)(d), (long)(e), (long)(f))

However it may (will?) end up including SYS_socketcall fallback code
even on archs that never need it if SYS_socketcall is defined.
Probably arch/*/syscall_arch.h should #undef SYS_socketcall if it's
never needed. I'm not sure if there are any such archs.

I kinda just thought of getting rid of the __socketcall abstraction,
but indeed it looks like a lot of ugly boilerplate to duplicate across
~15 functions, so I think keeping it in src/internal/syscall.h makes
the most sense.

Rich

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [musl] [PATCH] use new socket syscalls, fallback to socketcall
  2020-08-04 19:15               ` Rich Felker
@ 2020-08-06  2:18                 ` Rich Felker
  0 siblings, 0 replies; 6+ messages in thread
From: Rich Felker @ 2020-08-06  2:18 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

On Tue, Aug 04, 2020 at 03:15:06PM -0400, Rich Felker wrote:
> On Tue, Aug 04, 2020 at 08:56:42PM +0200, Markus Wichmann wrote:
> > On Tue, Aug 04, 2020 at 02:18:45PM -0400, Rich Felker wrote:
> > > Of these, only ppc, ppc64, sh, and possibly s390 (we only support
> > > 64-bit "s390x" and I'm not sure if it ever lacked the broken-down
> > > syscalls) are relevant. The rest are either unsupported by musl
> > > (including pre-EABI arm) or already using SYS_socketcall.
> > 
> > According to musl source, all currently supported architectures have
> > __NR_socket (I didn't check the other calls; I just assumed that
> > __NR_socket was a stand-in for all the other ones).
> > 
> > Therefore the required change can be performed by changing the
> > __socketcall macro (and __socketcall_cp of course). Something like this,
> > maybe? (If using GCC statement expressions is alright):
> > 
> > #ifdef __NR_socketcall
> > #define __socketcall(nm, a, b, c, d, e, f) \
> >     ({int r = __syscall(__NR_ ## nm, a, b, c, d, e, f); \
> >     if (r == -ENOSYS) \
> >         r = __syscall(__NR_socketcall, __SC_ ## nm, \
> >             (long[6]){(long)a, (long) b, (long)c, (long)d, (long)e, (long) f});
> >     r;})
> > #else
> > #define __socketcall(nm, a, b, c, d, e, f) __syscall(__NR_ ## nm, a, b, c, d, e, f)
> > #endif
> 
> This would work, but we don't use statement-expressions in musl. I
> think an alternative with an inline function would be trivial, though:
> 
> static inline long __socketcall(int sys, int sock, long a, long b, long c, long d, long e, long f)
> {
> 	long r = __syscall(sys, a, b, c, d, e, f);
> 	if (r != -ENOSYS) return r;
> 	return __syscall(SYS_socketcall, sock, ((long[6]){a, b, c, d, e, f}));
> }
> #define __socketcall(nm, a, b, c, d, e, f) __socketcall(SYS_##nm, __SC_##nm, \
> 	(long)(a), (long)(b), (long)(c), (long)(d), (long)(e), (long)(f))
> 
> However it may (will?) end up including SYS_socketcall fallback code
> even on archs that never need it if SYS_socketcall is defined.
> Probably arch/*/syscall_arch.h should #undef SYS_socketcall if it's
> never needed. I'm not sure if there are any such archs.
> 
> I kinda just thought of getting rid of the __socketcall abstraction,
> but indeed it looks like a lot of ugly boilerplate to duplicate across
> ~15 functions, so I think keeping it in src/internal/syscall.h makes
> the most sense.

OK, that roughly works. Special care is needed for SYS_accept since it
doesn't exist on i386, m68k, or s390x and needs to be emulated with
SYS_accept4. microblaze and mips (plain o32) seem to be the only archs
that define SYS_socketcall but don't ever need to use it.

Attached is a patch that seems to work implementing the above idea
with fixups. It's not heavily tested yet.

Rich

[-- Attachment #2: socketcall_fallback.diff --]
[-- Type: text/plain, Size: 3921 bytes --]

diff --git a/arch/i386/syscall_arch.h b/arch/i386/syscall_arch.h
index 69642e57..f92b7aa9 100644
--- a/arch/i386/syscall_arch.h
+++ b/arch/i386/syscall_arch.h
@@ -87,5 +87,3 @@ static inline long __syscall6(long n, long a1, long a2, long a3, long a4, long a
 #define VDSO_CGT32_VER "LINUX_2.6"
 #define VDSO_CGT_SYM "__vdso_clock_gettime64"
 #define VDSO_CGT_VER "LINUX_2.6"
-
-#define SYSCALL_USE_SOCKETCALL
diff --git a/arch/m68k/syscall_arch.h b/arch/m68k/syscall_arch.h
index af79c306..6a9d0ae8 100644
--- a/arch/m68k/syscall_arch.h
+++ b/arch/m68k/syscall_arch.h
@@ -87,5 +87,4 @@ static inline long __syscall6(long n, long a, long b, long c, long d, long e, lo
 	return d0;
 }
 
-#define SYSCALL_USE_SOCKETCALL
 #define SYSCALL_IPC_BROKEN_MODE
diff --git a/arch/microblaze/syscall_arch.h b/arch/microblaze/syscall_arch.h
index 169013f8..61d8248e 100644
--- a/arch/microblaze/syscall_arch.h
+++ b/arch/microblaze/syscall_arch.h
@@ -95,3 +95,5 @@ static inline long __syscall6(long n, long a, long b, long c, long d, long e, lo
 }
 
 #define SYSCALL_IPC_BROKEN_MODE
+
+#undef SYS_socketcall
diff --git a/arch/mips/syscall_arch.h b/arch/mips/syscall_arch.h
index 380a94b3..5b7c38de 100644
--- a/arch/mips/syscall_arch.h
+++ b/arch/mips/syscall_arch.h
@@ -149,3 +149,5 @@ static inline long __syscall7(long n, long a, long b, long c, long d, long e, lo
 
 #define SO_SNDTIMEO_OLD 0x1005
 #define SO_RCVTIMEO_OLD 0x1006
+
+#undef SYS_socketcall
diff --git a/arch/s390x/syscall_arch.h b/arch/s390x/syscall_arch.h
index afb99852..83cc9a27 100644
--- a/arch/s390x/syscall_arch.h
+++ b/arch/s390x/syscall_arch.h
@@ -72,5 +72,3 @@ static inline long __syscall6(long n, long a, long b, long c, long d, long e, lo
 	register long r7 __asm__("r7") = f;
 	__asm_syscall("+r"(r2), "r"(r1), "r"(r3), "r"(r4), "r"(r5), "r"(r6), "r"(r7));
 }
-
-#define SYSCALL_USE_SOCKETCALL
diff --git a/src/internal/syscall.h b/src/internal/syscall.h
index 975a0031..bd073c1a 100644
--- a/src/internal/syscall.h
+++ b/src/internal/syscall.h
@@ -2,6 +2,7 @@
 #define _INTERNAL_SYSCALL_H
 
 #include <features.h>
+#include <errno.h>
 #include <sys/syscall.h>
 #include "syscall_arch.h"
 
@@ -57,15 +58,23 @@ hidden long __syscall_ret(unsigned long),
 #define __syscall_cp(...) __SYSCALL_DISP(__syscall_cp,__VA_ARGS__)
 #define syscall_cp(...) __syscall_ret(__syscall_cp(__VA_ARGS__))
 
-#ifndef SYSCALL_USE_SOCKETCALL
-#define __socketcall(nm,a,b,c,d,e,f) __syscall(SYS_##nm, a, b, c, d, e, f)
-#define __socketcall_cp(nm,a,b,c,d,e,f) __syscall_cp(SYS_##nm, a, b, c, d, e, f)
+static inline long __alt_socketcall(int sys, int sock, int cp, long a, long b, long c, long d, long e, long f)
+{
+	long r;
+	if (cp) r = __syscall_cp(sys, a, b, c, d, e, f);
+	else r = __syscall(sys, a, b, c, d, e, f);
+	if (r != -ENOSYS) return r;
+#ifndef SYS_socketcall
+	return r;
 #else
-#define __socketcall(nm,a,b,c,d,e,f) __syscall(SYS_socketcall, __SC_##nm, \
-    ((long [6]){ (long)a, (long)b, (long)c, (long)d, (long)e, (long)f }))
-#define __socketcall_cp(nm,a,b,c,d,e,f) __syscall_cp(SYS_socketcall, __SC_##nm, \
-    ((long [6]){ (long)a, (long)b, (long)c, (long)d, (long)e, (long)f }))
+	if (cp) return __syscall_cp(SYS_socketcall, sock, ((long[6]){a, b, c, d, e, f}));
+	else return __syscall(SYS_socketcall, sock, ((long[6]){a, b, c, d, e, f}));
 #endif
+}
+#define __socketcall(nm, a, b, c, d, e, f) __alt_socketcall(SYS_##nm, __SC_##nm, 0, \
+	(long)(a), (long)(b), (long)(c), (long)(d), (long)(e), (long)(f))
+#define __socketcall_cp(nm, a, b, c, d, e, f) __alt_socketcall(SYS_##nm, __SC_##nm, 1, \
+	(long)(a), (long)(b), (long)(c), (long)(d), (long)(e), (long)(f))
 
 /* fixup legacy 16-bit junk */
 
@@ -338,6 +347,10 @@ hidden long __syscall_ret(unsigned long),
 #define __SC_recvmmsg    19
 #define __SC_sendmmsg    20
 
+#ifndef SYS_accept
+#define SYS_accept SYS_accept4
+#endif
+
 #ifndef SO_RCVTIMEO_OLD
 #define SO_RCVTIMEO_OLD  20
 #endif

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-08-06  2:19 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-03  7:41 [musl] Add SYSCALL_USE_SOCKETCALL for old arch David Timber
2020-08-03 13:33 ` Rich Felker
     [not found]   ` <CAGYH49BV-SG0THP2kzbSVVRypkk0APF1MQb74geskos=dDLv6A@mail.gmail.com>
     [not found]     ` <CAGYH49Dd6qMK0pL+eGBzMZPxBqoZhRRfejnsvkkSsN+xcw4njg@mail.gmail.com>
     [not found]       ` <20200803141513.GD6949@brightrain.aerifal.cx>
     [not found]         ` <CAGYH49AEpS9_ndXP=x20Qpj7tx0RBEyt+iB5nEjD4odUW02wiQ@mail.gmail.com>
2020-08-04 18:18           ` Rich Felker
2020-08-04 18:56             ` Markus Wichmann
2020-08-04 19:15               ` Rich Felker
2020-08-06  2:18                 ` [musl] [PATCH] use new socket syscalls, fallback to socketcall Rich Felker

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git