From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12498 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Possible patch for __syscall_cp Date: Tue, 13 Feb 2018 15:49:55 +0100 Message-ID: <20180213144955.GB4418@port70.net> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1518533326 28082 195.159.176.226 (13 Feb 2018 14:48:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Feb 2018 14:48:46 +0000 (UTC) User-Agent: Mutt/1.9.1 (2017-09-22) To: musl@lists.openwall.com Original-X-From: musl-return-12514-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 13 15:48:42 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1elbsJ-0004g4-6c for gllmg-musl@m.gmane.org; Tue, 13 Feb 2018 15:48:03 +0100 Original-Received: (qmail 31871 invoked by uid 550); 13 Feb 2018 14:50:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 31847 invoked from network); 13 Feb 2018 14:50:06 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12498 Archived-At: * Nicholas Wilson [2018-02-13 14:28:32 +0000]: > > In __syscall_cp.c, there's a call to __syscall which deliberately *disables* macro expansion, forcing the call to go via the __syscall function. On Wasm, I don't currently provide this function, instead I'm using the macros for __syscall to redirect via the __syscall functions. > > This call in __syscall_cp looks to be practically the only place in the whole of Musl where macro expansion is prevented for __syscall (other than in src/internal/syscall.h itself, and arch/mips/syscall_arch.h). So on those grounds it's a bit suspicious, given that every other caller of __syscall uses the macros from internal/syscall.h. > > If there is a rationale, I could just define __syscall() in arch/wasm/syscall_arch.h - but I'd rather not if it's not meant to be called. Would it be possible instead to apply the patch below, and allow macro expansion? > > I can't see a risk, although I don't understand the cancellation-point implementation very well. There's no recursion possible, since plain __syscall() never redirects to any of the __syscall_cp machinery, so expansion oughtn't to cause problems on any archs? > i think your patch is ok (__syscall6 should behave the same way as __syscall other than the inlining), but you can fix it for your target only by adding static inline long __syscall(long n, long a, long b, long c, long d, long e, long f) { return __syscall6(n,a,b,c,d,e,f); } to syscall_arch.h > diff --git a/src/thread/__syscall_cp.c b/src/thread/__syscall_cp.c > index 09a2be84..7b870faa 100644 > --- a/src/thread/__syscall_cp.c > +++ b/src/thread/__syscall_cp.c > @@ -8,7 +8,7 @@ static long sccp(syscall_arg_t nr, > syscall_arg_t u, syscall_arg_t v, syscall_arg_t w, > syscall_arg_t x, syscall_arg_t y, syscall_arg_t z) > { > - return (__syscall)(nr, u, v, w, x, y, z); > + return __syscall(nr, u, v, w, x, y, z); > } > > weak_alias(sccp, __syscall_cp_c);