From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1280 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: mips port working! & remaining issues Date: Fri, 13 Jul 2012 01:23:13 -0400 Message-ID: <20120713052313.GA20369@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 X-Trace: dough.gmane.org 1342157059 3391 80.91.229.3 (13 Jul 2012 05:24:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2012 05:24:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1281-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 13 07:24:19 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 1SpYMU-0006cZ-DE for gllmg-musl@plane.gmane.org; Fri, 13 Jul 2012 07:24:18 +0200 Original-Received: (qmail 4003 invoked by uid 550); 13 Jul 2012 05:24:17 -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 3995 invoked from network); 13 Jul 2012 05:24:17 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1280 Archived-At: Hi all, According to libc-testsuite, the new mips port of musl is working. If remaining issues exist, I suspect they're in the bits/*.h files' definitions of kernel constants and structures, which I could use some help reviewing. Threads, including cancellation, are known to work, and mipsel (little endian) mode presumably works but is untested. One major omission that remains is the dynamic linker. Due to mips o32's pathologically bad PIC ABI which has no PC-relative addressing, the current dynamic linker cannot work as-is. Rather than replacing it with an ugly mess of fragile early-stage code that depends on non-optimization by the compiler (the way traditional dynamic linkers work), I'd rather simply require the dynamic linker and libc to be loaded at a fixed address chosen at build time -- this is basically what prelink does. We may be able to use the existing prelink tools, or just write a small special-purpose tool to prepare libc.so for loading at a fixed address. Another major omission shared with arm is that setjmp/longjmp cannot preserve floating point registers. This is because I don't yet know how to determine at runtime whether hard-float is available, and the registers can't be saved unless they can be determined to exist. Help solving this problem would also be appreciated. Rich