Re: Hi and a few questions

[Richard Pennington <rich@pennware.com>]

On Sunday, May 20, 2012 01:21:16 PM Rich Felker wrote:
> 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.

Good. I'll start working on the ports, then. I also use QEMU for testing, 
generally using QEMU Linux user space emulation.


> 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.

I agree, I haven't done a complete analysis yet, but many of the errors are 
because -Werror is set and also because of the missing pthread_setschedparam 
and friends.

> 
> > 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..

Thinking about it, I agree that changing the build/install doesn't add much 
value. I think I'll use your normal build/install.

> 
> > 	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
> 

Understood. I should be able to reuse some of the assembly language support 
stuff (startup, setjmp/longjmp, etc.) that I've already written for the other 
targets, I'll just model them after yours.

> > 	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.

Good. I'll get to work.

-Rich