[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6044018.irMazzkhHx@main.pennware.com>
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.
