[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+fZqCWRwFOu-SbAOjaUtdBd1nuALpMugQvrn9nf6CfHeUOxbQ@mail.gmail.com>
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.
