[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Dec 2017 09:18:18 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Feature request: building musl in a portable way
On Fri, Dec 22, 2017 at 08:04:31PM +0100, ardi wrote:
> On Fri, Dec 22, 2017 at 5:43 PM, Rich Felker <dalias@...c.org> 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
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.
