Re: Feature request: building musl in a portable way

[Markus Wichmann <nullplan@gmx.net>]

On Fri, Dec 22, 2017 at 08:04:31PM +0100, ardi wrote:
> On Fri, Dec 22, 2017 at 5:43 PM, Rich Felker <dalias@libc.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