From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/856 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hi and a few questions Date: Sun, 20 May 2012 13:21:16 -0400 Message-ID: <20120520172116.GA163@brightrain.aerifal.cx> References: <1753849.ANqesc5nEP@main.pennware.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1337534804 11037 80.91.229.3 (20 May 2012 17:26:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 20 May 2012 17:26:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-857-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 20 19:26:43 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SW9tu-0002oe-0D for gllmg-musl@plane.gmane.org; Sun, 20 May 2012 19:26:38 +0200 Original-Received: (qmail 22045 invoked by uid 550); 20 May 2012 17:26:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22037 invoked from network); 20 May 2012 17:26:37 -0000 Content-Disposition: inline In-Reply-To: <1753849.ANqesc5nEP@main.pennware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:856 Archived-At: 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