Re: Hi and a few questions

[Rich Felker <dalias@aerifal.cx>]

On Sun, May 20, 2012 at 12:03:20PM -0500, Richard Pennington wrote:
> I want to target several processors, including i386, x86_64, arm,
> mips, microblaze, ppc, and ppc64 so it looks like musl support will
> have to be added for the currently unsupported processors.

Yes, and I'd be very happy to get support added. The reason for lack
of ports is not lack of portability but lack of knowledge about these
targets. I read up on ARM and did the ARM port using qemu / Aboriginal
Linux boot images just because I found it a bit shameful to only
support x86[_64], but I haven't gotten around to doing this with any
others.

> I've done some preliminary testing by compiling the Open POSIX Test Suite 
> (http://posixtest.sourceforge.net) three ways:
> 	1. with gcc/glibc, x86_64
> 	2. with clang/LLVM/glibc, x86_64
> 	3. with clang/LLVM/musl, x86_64
> 
> The results have been good enough that I'm pretty sure I want to switch:
> 
> [~/ellcc/posixtestsuite] main% grep PASS logfile.musl | wc
>    5074   15286  275399
> [~/ellcc/posixtestsuite] main% grep PASS logfile.ecc | wc
>    5381   16143  294510
> [~/ellcc/posixtestsuite] main% grep PASS logfile.gcc | wc
>    5380   16140  294458

I suspect the situation is somewhat better than these results
indicate. Open POSIX Test Suite, while useful, has a number of tests
that are incorrect/invalid (mostly, by virtue of invoking undefined
behavior then testing the behavior) that actually test for glibc
behavior rather than POSIX. As far as I know, all of the tests musl
fails to PASS are either (1) of this form, or (2) testing features
(like priority scheduling) that musl does not yet support.

> Now for my questions:
> 	1. Can musl be built out of the source tree? I'd like to be able to build
> 	    for different processors in different directories.

At present, no. Even if the trivial changes were made to put the .o
files somewhere else, there's also the issue of the include/bits
symlink (which could actually be removed since arch/$(ARCH) is also in
the -I path, but doing so would complicate the install rules and
preclude using musl "in-place" without "make install" which is
presently possible and a useful setup.

I'd welcome ideas (though I'd have to weigh whether to adopt them) for
making this possible, but the source is small enough that I wonder if
it's really necessary..

> 	2. Are the include/bits files the only include files that differ between
>             processors?

No, include/bits is just the _public_ differences to the interfaces.
There are also some internal headers in the arch/$(ARCH) directories,
but more importantly, musl's build system implicitly replaces any
source file foo.c with $(ARCH)/foo.s if the latter exists. Some of
these replacements (e.g. all the ones in math) are purely size/speed
optimizations, but most are essential, functions that cannot be
implemented except in assembly: setjmp/longjmp, clone, dlsym, and some
internal stuff:

- cancellation-point syscalls: needs to store stack/instruction
  pointer values so a thread can tell if it is blocked at a
  cancellation point when a cancellation request arrives.

- thread exiting: needs to call munmap on its own stack, obviously
  without touching the stack after the syscall returns.

- setting up the thread pointer register: this is arch-specific.

- startup code (crt/*): must convert the initial register/stack
  contents into arguments for __libc_start_main

> 	3. Are people actively working on other musl ports? I'd wouldn't want to
> 	    duplicate their efforts.

No. There's been some talk in the past, but no code.

> Sorry for the basic questions, but I just started looking at musl this 
> morning. ;-)

No problem. I don't mind answering at all; these are good questions
and it's useful to have the answers on the mailing list archive.

Rich