From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12284 Path: news.gmane.org!.POSTED!not-for-mail From: ardi Newsgroups: gmane.linux.lib.musl.general Subject: Re: Feature request: building musl in a portable way Date: Sat, 23 Dec 2017 21:57:47 +0100 Message-ID: References: <20171221213822.GY1627@brightrain.aerifal.cx> <20171222164339.GB1627@brightrain.aerifal.cx> <20171223081818.jus6ggz5eexkln26@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1514062573 5613 195.159.176.226 (23 Dec 2017 20:56:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 20:56:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12300-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 23 21:56:09 2017 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 1eSqpz-0000iC-M6 for gllmg-musl@m.gmane.org; Sat, 23 Dec 2017 21:56:07 +0100 Original-Received: (qmail 19786 invoked by uid 550); 23 Dec 2017 20:58:02 -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 19735 invoked from network); 23 Dec 2017 20:58:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3MgOk5/FL/h00J83x8YRTpK1aaSz4L5kkDuqka2BQPY=; b=kXaENz0PpNFHkhhaFh6kLUUxAD0Tum6/hpZn4tjCkS89dDNiIFZ2Aayxd3X/DqOllL 9Br36u2quVr5cfN+iJ3669OUrJpQKhhs1k0Se0O5OXDUtcBbsNTm+MCT7W6QaA6Hcu0z 0ujHiU03Df5l/p+Md1qhHftc7HZKVuFyHk7DkSnso8DPgrrZ6C59AfaulwGUjbuLykqS s5KuWxxxN4gF+cwSrIn5RNr8vmQvZ3/m66RRCUTz09HKXVKdkvFwSkJbML6j2POGPZv3 liMFOBP6lto75DAVYifrxZqMn3hdlmSCfZNkUr+LvQkeI+XInGR9x+l8deXnNyqWxC6v vEwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3MgOk5/FL/h00J83x8YRTpK1aaSz4L5kkDuqka2BQPY=; b=UD0514CCbNQZfX+CPdRvnRCgl/BM3sAgLyxWjU+XtHalrSaXOGtQDOIaxgJXkJ4s5i Ed2zU3YtSUjh60XhGbYl4Atn1jriaBb79a9IQ7do0rG/LeMYwj8Fk86rr8HZpaP7NBl/ txJmgWWaHuFpBzopYghEFR6jtoSxWd5DeBnWyD9E0qXq5ZSVwizF/fZEzTzjJM7Cx0Vq 45I2uSj0DHVH8l4vZG1O9x7DFb8DL79XOKiqifCHul8cwbENs5S+dRaYWyJjbII+19o4 y8MfTFjaQyEnjguCqy2DKNzn23eM2XiFul5I6Hd3NB3kW/FgpzGjhUnVl8AuiEo9Mhve q52Q== X-Gm-Message-State: AKGB3mJmRNULoSr0KwQ6R/53abYSOQdgwY1Ut16TIp08seZ7SPNNQ65h u7EDARlZiUaYAT5Vb/jnnxnpuNk+G6rDwA5WQFVSCg== X-Google-Smtp-Source: ACJfBovr+/8qKOWaXp0AQ7RCj5HMFq2D0Z9PLXrfrQYUpvU4v1oDhSrTrvgo3NLKtMcGml0UCQFkiFQQwpv8JMHtTOU= X-Received: by 10.101.76.3 with SMTP id u3mr16039619pgq.136.1514062668938; Sat, 23 Dec 2017 12:57:48 -0800 (PST) In-Reply-To: <20171223081818.jus6ggz5eexkln26@voyager> Xref: news.gmane.org gmane.linux.lib.musl.general:12284 Archived-At: On Sat, Dec 23, 2017 at 9:18 AM, Markus Wichmann wrote: > Clean it might be, but it's also long and stony. Linux currently > supports ca. 300 syscalls. Does musl use all Linux syscalls? In the musl headers I found traces of about 60 or so syscall IDs definitions, IIRC (or even less, I don't remember now). [...] > - musl requires mmap() with MAP_FIXED on a previously allocated area to > work for shared libraries. In fact, musl itself will use mmap() with > MAP_FIXED _only_ on previously allocated areas. There are reasons for > that, but suffice it to say that for instance Cygwin fails these > calls. Does musl explicitly query for MAP_FIXED in the proper syscall arguments when it expects MAP_FIXED, or do you have to guess it? If musl explicitly queries for MAP_FIXED through the syscall arguments, I don't see any problem here, just parse the arguments and pass the MAP_FIXED requirement to the host syscall. > - musl requires the close() syscall to always release the file descriptor > if it was allocated before. Even if the call itself fails for any > reason. > - musl assumes the credential setting functions to have thread-local > effect. Since POSIX defines them to have a process-global effect, it > goes to some length to match them up. I am not certain every OS is as > quirky in that respect as Linux (that's the real issue). > - musl assumes to be able to read the instruction pointer from the > arguments to signal handler, and to be able to set it. Thanks a lot for all these advices!! [...] >> Yes, I believe that whenever there are assembly source files in some >> directory in the musl tree, there're functions there that make >> syscalls without going through the interface you defined above. I'll >> look at this and I'll see if it can be improved somehow. >> > > Ooh, thanks, that reminded me: the assembly files do make syscalls > wildly, usually for control of the stack of because the other arch's > need it. For instance src/thread/i386/__set_thread_area.s does nothing > but invoke two syscalls. But it is needed to be an assembly file, since > for some other arch's (e.g. PowerPC), only a register move is required. Yeah, that's my main worry: the musl functions that issue syscalls directly in assembly on their own, bypassing the musl syscall main interface. I still need to look at this. Thanks! ardi