|
Message-ID: <20171223081818.jus6ggz5eexkln26@voyager> 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.