Date: Sat, 23 Dec 2017 21:57:47 +0100 From: ardi <ardillasdelmonte@...il.com> To: musl@...ts.openwall.com Subject: Re: Feature request: building musl in a portable way On Sat, Dec 23, 2017 at 9:18 AM, Markus Wichmann <nullplan@....net> wrote: > Clean it might be, but it's also long and stony. Linux currently > supports ca. 300 syscalls. Does musl use all Linux syscalls? In the musl headers I found traces of about 60 or so syscall IDs definitions, IIRC (or even less, I don't remember now). [...] > - 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. Does musl explicitly query for MAP_FIXED in the proper syscall arguments when it expects MAP_FIXED, or do you have to guess it? If musl explicitly queries for MAP_FIXED through the syscall arguments, I don't see any problem here, just parse the arguments and pass the MAP_FIXED requirement to the host syscall. > - 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. Thanks a lot for all these advices!! [...] >> 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. Yeah, that's my main worry: the musl functions that issue syscalls directly in assembly on their own, bypassing the musl syscall main interface. I still need to look at this. 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.