Date: Fri, 22 Dec 2017 17:09:06 +0100 From: ardi <ardillasdelmonte@...il.com> To: musl@...ts.openwall.com Subject: Re: Feature request: building musl in a portable way On Thu, Dec 21, 2017 at 10:38 PM, Rich Felker <dalias@...c.org> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.