[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
