Re: Feature request: building musl in a portable way

[ardi <ardillasdelmonte@gmail.com>]

On Sat, Dec 23, 2017 at 9:18 AM, Markus Wichmann <nullplan@gmx.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