Date: Sun, 20 May 2012 14:57:33 -0500 From: Richard Pennington <rich@...nware.com> To: musl@...ts.openwall.com Subject: Re: Hi and a few questions 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
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.