From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12272 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: Fri, 22 Dec 2017 17:09:06 +0100 Message-ID: References: <20171221213822.GY1627@brightrain.aerifal.cx> 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 1513958849 2273 195.159.176.226 (22 Dec 2017 16:07:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2017 16:07:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12288-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 22 17:07:25 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 1eSPqy-0008Qa-6H for gllmg-musl@m.gmane.org; Fri, 22 Dec 2017 17:07:20 +0100 Original-Received: (qmail 15841 invoked by uid 550); 22 Dec 2017 16:09: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: Original-Received: (qmail 15823 invoked from network); 22 Dec 2017 16:09:18 -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=GQSYaGfBXHYlibb/SqwnHc3pWvtnfN56lMHy/1cbqf8=; b=Xsa+vlQeco0Lw9gWBcIa/9mQRE917pQWCdoXtsv/+bzwFlpjm0Nj7iueyP6O9ow6Xk B9cTSs+ofYOss4ljfFYELIB8z/pcxx71eJT9xTYslXE4gKPFi3IEdv9N/bHwWPku6xWw rDRmWglXDhCfcz0lAp5iXDbsCIXKhkDLzijubxA/A1v7DNrMDMIE8LjT82LjvucodMC7 AeRakKSiVUhhJcde8HKsciMVTso48scoXppZz0YJYUgTWWx50FuUEI4SxgbT9Dk1JX+m Q+RtmGQdeQagR/v7XNyQBM0haNjWH0mogBqfr63JK7noMcwXgiexKyco5iOUmBc/fBZm /GRA== 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=GQSYaGfBXHYlibb/SqwnHc3pWvtnfN56lMHy/1cbqf8=; b=cNwbZQxa34KmSEpgQWVallrqohGA/ZXg1Ied86r5mhhMkWvlCT2WVqz7N5/Yurj5Jg TTgEjpo+KOFcr8rvAM1b+c+LkseegYyPiJcyw1H2lPpXyXSMWxe04P3mTUPai9ZxN5Xg DPb8eh+CB7Oe7EsBJEyxI67jhrwZeaFUmqxpW4aDbEKqtXZ7w27PvX1nv2RfrVi1fskG 7FhapuDMba1UO7J3F0VzUPUVX3MlJqOKfPFNZw0bED2YcJN2u/mh4lvr7TleH21tiNIn 2xDN7CZ4P/jtBESEgeb5bccJv3S2WLMBlkUjd6J/UjbOOUcsoblclrqDVbKniHDYIOh7 62uw== X-Gm-Message-State: AKGB3mJ+7VjfC+Ki0f1uHbPo5VYn2E7mYYd1hjOWm5ogqT85BVwpbcWe 8pMdcSH1YKBXBtWb6nWKEp/xJxBw8h1S8J5jeYQ= X-Google-Smtp-Source: ACJfBov3MTNSNDASdoeLuHYfk/ggnIupFuDYRemlAO7wjzR0jaFLoouNIG9KQp6nMoMWKG6HMaXrj7j3428cLPNFz/8= X-Received: by 10.99.64.199 with SMTP id n190mr12770426pga.296.1513958946635; Fri, 22 Dec 2017 08:09:06 -0800 (PST) In-Reply-To: <20171221213822.GY1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12272 Archived-At: On Thu, Dec 21, 2017 at 10:38 PM, Rich Felker wrote: [...] > > I'm not clear what you want to do. I'm looking for a C runtime with a MIT-like license that can be compiled for several architectures, in 32bit and 64bit, mostly Intel, PowerPC, ARM, and MIPS, and is endian-safe, and written in a tidy code. I need that such runtime is able to be retargeted to different OSs by changing the layer where syscalls are made. At the moment of writing this, the OSs I'm interested in are Linux and MacOS. In the future I'll likely be interested in other OSs as well. I don't know of any C runtime that meets all these requirements. The only two that get close are the different BSDs C runtimes, and musl, but both lack the last requirement (i.e.: syscalls are not encapsulated in some confined files so that you could rewrite such "syscall layer" for each OS --instead, syscalls can be issued from any place in code, and the only way to locate and encapsulate the proper functions is to manually search for invocations of syscalls in the source tree). So, only options are BSDs and musl (unless I forget any). But both BSDs and musl require "heavy editing" if you want to encapsulate syscalls, and by doing such editing, you place yourself out of easily updating to newer versions without considerable merging work. > A program that doesn't make > syscalls has no input except argv[] and environ[], does not terminate, > and has no output. So such a build of musl is certainly not useful as > a libc. Yes, I didn't explain it well. Of course the program will make syscalls. But they will happen only within a confined set of functions that I can rewrite for different OSs. > Even if it were, configurable builds that exclude > functionality are intentionally outside the scope of musl; instead, > the project provides fine-grained linking so that you just get what > you need; ports to systems where some underlying functionality is not > possible simply need to make the relevant syscalls fail with ENOSYS. There's more to that: musl assumes syscalls are invoked following the Linux kernel protocol for syscalls. It's not only a matter of translating syscalls numbers and their arguments, but about how the syscalls are triggered. So, writing the "compatibility layer" that I explained in the previous paragraphs is much harder if it has to intercept and translate syscalls, than if you could edit the musl files where syscalls are invoked, redirecting them in a more comfortable way, and without the tough code for intercepting syscalls. > With that said, my guess is that you're really asking for a way to > take the "pure" code out of musl and make it a library that you can > use on an existing C/POSIX (or non-POSIX C) implementation. This is > interesting, but currently outside the scope of musl, and probably > covers less interesting code than you might expect [...] I'm not interested in taking the "pure" code only, but as much code as possible, only having to rewrite the syscall retargeting layer. > [...] Making it easier to use them outside musl > is an interesting problem but I'm afraid not one I have resources to > devote to at present.. A somewhat crazy idea came to my mind: libraries like ElectricFence, that substitute libc functions by their own version if you link them before the C runtime. This would let me replace functions that make syscalls by my own version. However, it sounds quite hack-ish and error-prone in the long run. After thinking about this, I believe the best way would be to be able to confine all the musl syscalls invocations in a reduced place that I can take control of. In the current directory tree, musl has a function for making syscalls, and this would be exactly what I need: a place for easily intercepting syscalls and redirecting them. However, several functions in musl invoke syscalls directly in assembly, without going through that function, so it's not easy to intercept all syscalls in this moment. Do you foresee a possibility of building musl so that all syscalls go through some function that I can easily intercept **before** the syscall is actually invoked? Thanks! ardi