From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/858 Path: news.gmane.org!not-for-mail From: Richard Pennington Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hi and a few questions Date: Sun, 20 May 2012 14:57:33 -0500 Message-ID: <6044018.irMazzkhHx@main.pennware.com> References: <1753849.ANqesc5nEP@main.pennware.com> <20120520172116.GA163@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: dough.gmane.org 1337543937 9533 80.91.229.3 (20 May 2012 19:58:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 20 May 2012 19:58:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-859-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 20 21:58:54 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 1SWCHE-0005qz-Q9 for gllmg-musl@plane.gmane.org; Sun, 20 May 2012 21:58:52 +0200 Original-Received: (qmail 3362 invoked by uid 550); 20 May 2012 19:58:52 -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 3354 invoked from network); 20 May 2012 19:58:52 -0000 X-Authority-Analysis: v=2.0 cv=ae7jbGUt c=1 sm=0 a=/l7PkcR/UKDnn7Q2wmGJww==:17 a=hdNgKtvFP3AA:10 a=fR_ARpL9IlcA:10 a=msTO8fkKGJEA:10 a=kj9zAlcOel0A:10 a=N4Ps669bAAAA:8 a=chffEtAQnhYrGCwYnzYA:9 a=lucSYezefbUx0zecSBMA:7 a=CjuIK1q_8ugA:10 a=/l7PkcR/UKDnn7Q2wmGJww==:117 X-Cloudmark-Score: 0 X-Originating-IP: 65.26.59.215 User-Agent: KMail/4.8.3 (Linux/3.3.2-6.fc16.x86_64; KDE/4.8.3; x86_64; ; ) In-Reply-To: <20120520172116.GA163@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:858 Archived-At: 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