From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SUBJ_OBFU_PUNCT_FEW autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8145 invoked from network); 4 Aug 2020 19:15:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2020 19:15:22 -0000 Received: (qmail 20051 invoked by uid 550); 4 Aug 2020 19:15:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20026 invoked from network); 4 Aug 2020 19:15:18 -0000 Date: Tue, 4 Aug 2020 15:15:06 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200804191506.GJ6949@brightrain.aerifal.cx> References: <20200803133338.GB6949@brightrain.aerifal.cx> <20200803141513.GD6949@brightrain.aerifal.cx> <20200804181845.GI6949@brightrain.aerifal.cx> <20200804185642.GG2076@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200804185642.GG2076@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Add SYSCALL_USE_SOCKETCALL for old arch 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