From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12281 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Feature request: building musl in a portable way Date: Sat, 23 Dec 2017 09:18:18 +0100 Message-ID: <20171223081818.jus6ggz5eexkln26@voyager> References: <20171221213822.GY1627@brightrain.aerifal.cx> <20171222164339.GB1627@brightrain.aerifal.cx> 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 1514017004 7261 195.159.176.226 (23 Dec 2017 08:16:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 08:16:44 +0000 (UTC) User-Agent: NeoMutt/20170609 (1.8.3) To: musl@lists.openwall.com Original-X-From: musl-return-12297-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 23 09:16:40 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 1eSeyy-0001Qu-B0 for gllmg-musl@m.gmane.org; Sat, 23 Dec 2017 09:16:36 +0100 Original-Received: (qmail 31848 invoked by uid 550); 23 Dec 2017 08:18:35 -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 31830 invoked from network); 23 Dec 2017 08:18:34 -0000 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K0:TL0iTN+GBwpe9pgoyUI8eGCf7cdOcvYUUS67Bdvvp56M2H+WbGp cxuMLa/zIw7Az56GRUrohbCU8H+FQpkGaRzXysdTxlzu0cjJkk5VQzWTXIUJO0B5skGzV/w 8Cv2/IXl5RAzZcExzKRKY2BajObslP3iT9MDuNlWN8XfkafEu3StcJXqSlAHCnrMvGHj01O IFA9z4AqE2CkS1OkIk/Eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:GHZ76Hg5nEM=:7JKsQ6pnZ7kyA3t70Aytc/ Og52QexGd1HmnwqszWKeeRk3+s4KffBnJlLOngScBHCiBEdGD6yOTh9jId/x0RNgjLWfTh5lN FXDbNsTFOxBciPX48L++T2IaIrHbIn8KmUZXRBfhr0ROwajfrFf+Rpyn4Kp/KCHlkGvTEHIIz +GL8H7UI405rVnQwSUK94Tz6YK+vg71zsbKatRFktSX1zNhUsf987KnvNkOVy+JMf8J8UYDh5 EgiO6mJ8fzyA56Fm3yz6m7reZ69cWIGsgGyAAGb+0cmrYKCu/9fpWsrIBNoESURppcxQf8nEW 2WozaDFKM5y/QrwlcxpR8jj35l07FO+yhXhpPTa6QaMp7FiB8bEWfphgUzwzerQ9PsvXtXF4C AVznCXoUdJM4H3PWnTF4BqQFH+dyhz3WTpcjpzurITy1VMdilnJ0TXjswhdVpz83HwTyMBtM9 CCf5W6rjONW44xjgCnvz8WK138hrtUdqIUt/lobr/Yc+TMz1b5qwk/dko8CM9sZSq4UqNqtaR 1LBPCwAqQoxyClKuE9VIFTul5Tn11PPcEmLl0soiQ33+jmxEW3YBH3/4A7zD4DdHgaoefHdjP 65Aj1B3fimGbuTJKOIsL3KlYUbE0XghqqxgTdThLSJ5DGoIwJaUipzntYZpwS3uZcxjzhQ7a3 5ULMdB24tuXxmGwzq3zMfbcFiq9aQyWwnE+liJrUVN+whGAe7OT0UOoURo+LKc/q0tpWjxMqm NDo4a1IyczZWofmWAs4QeBygbFItse8dhymLBcWboJNnvkUoR5NRBC8wze9FL4ZrvqEVd5bb Xref: news.gmane.org gmane.linux.lib.musl.general:12281 Archived-At: On Fri, Dec 22, 2017 at 08:04:31PM +0100, ardi wrote: > On Fri, Dec 22, 2017 at 5:43 PM, Rich Felker wrote: > > [...] You can change the syscall layer just by > > making a new arch that defines (in syscall_arch.h and bits/syscall.h) > > your mechanism. See the recent wasm thread or midipix for examples of > > more exotic ways this can be done. > > Thanks a lot!! I'll try to follow this path. It looks clean. > > Clean it might be, but it's also long and stony. Linux currently supports ca. 300 syscalls. > > But be aware that the ability to > > get a POSIX-conforming implementation where EINTR and thread > > cancellation work requires some sort of atomic boundary that > > determines when a syscall has passed the point of having successful > > side effects, which makes implementing the syscalls just as functions > > hard. > > I'm not sure if I can hit this scenario but I'll research this. Thanks! > That's just one quirk of musl's use of syscalls, though. Here are some others, off the top of my head: - 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. - 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. [...] > > There are indeed a small number of places where workarounds or other > > considerations for Linux-specific parts of the syscall interface > > boundary are in general source files rather than in the syscall glue > > layer, but I think the number is quite small. If there are > > particularly egregious ones that you think could be improved upon, > > please let me know. > > 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. > Thanks a lot! > > ardi Ciao, Markus