Date: Tue, 15 Jul 2014 11:58:59 -0700 From: "Weiming Zhao" <weimingz@...eaurora.org> To: <musl@...ts.openwall.com> Subject: RE: AArch64 merge back Hi Rich, Thanks a lot for your response. We're trying static linking of AArch64 with some simple tests. Some simple tests are working, but we do see some syscall issue as you mentioned. We suspect it's related with arch/aarch64/bits/syscall.h. Is the file written from scratch or based on some existing open source projects? Thanks, Weiming -----Original Message----- From: Rich Felker [mailto:dalias@...ifal.cx] On Behalf Of Rich Felker Sent: Tuesday, July 01, 2014 11:25 AM To: musl@...ts.openwall.com Subject: Re: [musl] AArch64 merge back On Tue, Jul 01, 2014 at 10:41:10AM -0700, Weiming Zhao wrote: > Hi Isaac, > > So if I just want to use some arch-independent functions, then I just > need to build the main musl repo with aarch64 compiler. Is my > understanding correct? No. I didn't really understand what you were asking before, but it might be more clear if you read the porting documents on the wiki. Rather than trying to answer point by point I'll try to explain a few things: It's not possible to use musl on a new arch simply by compiling the arch-independent C. This is partly because there are a number of components of libc that fundamentally cannot be expressed in C, and partly because the kernel (gratuitously) has a different set of constants, struct definitions, etc. for each architecture. Generally ports are not merged (in the "git merge" sense) because most of the early work on them is a mess of incompleteness, trial-and-error, etc. Also merging would be a lot of work since we normally rebase all merges, whereas master has often diverged quite a bit before a port is ready to merge. Instead, once the port is working, we usually just add it as a single commit, followed by any fixes for issues that weren't found before commit. I'm not clear on the status of the aarch64 port right now. It was stalled for a while because of changes needed in many of the arch-independent files to accomodate the way the kernel does things on newer archs (omitting lots of simple syscalls that can be emulated using more complex ones). That work is done in mainline musl now though, so it's no longer blocking ports. Further progress is up to the people working on those ports (or anyone else who wants to build on their work). I'm really hoping it will be finished during this release cycle so we can have aarch64 support in 1.1.4. If you or anyone else wants to play around with trying to get it to work based on the in-progress ports, the best approach would be to simply copy over the new files added in the aarch64 musl git tree into a more recent musl (1.1.2 or later). 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.