From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2142 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Pending issues for release Date: Thu, 18 Oct 2012 18:58:22 -0400 Message-ID: <20121018225822.GI254@brightrain.aerifal.cx> References: <20121018182957.GA18080@brightrain.aerifal.cx> <20121018155421.44e6e86a.idunham@lavabit.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: ger.gmane.org 1350601633 14839 80.91.229.3 (18 Oct 2012 23:07:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Oct 2012 23:07:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2143-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 19 01:07:20 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 1TOzBH-0006GA-Nn for gllmg-musl@plane.gmane.org; Fri, 19 Oct 2012 01:07:11 +0200 Original-Received: (qmail 31784 invoked by uid 550); 18 Oct 2012 23:07:04 -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 31776 invoked from network); 18 Oct 2012 23:07:04 -0000 Content-Disposition: inline In-Reply-To: <20121018155421.44e6e86a.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2142 Archived-At: On Thu, Oct 18, 2012 at 03:54:21PM -0700, Isaac Dunham wrote: > On Thu, 18 Oct 2012 14:29:57 -0400 > Rich Felker wrote: > > > Hi all, > > Once I confirm that there are no stupid bugs blocking threads from > > working on microblaze (so far I have been unable to test due to buggy > > qemu), I'd like to make a release. Pending issues I'd like to address > > before then include: > > > > - dl_iterate_phdr patch (npx) > > - sigreturn(?) and other issues npx wanted for unwinding > > - integrating the configure patch for better pcc support > > Are there any further comments on that? I don't think the trycc is needed. If pcc is the only compiler installed, c99 or cc should be a symlink/wrapper for it. Trying it _after_ cc/c99 is almost surely not the right thing to do anyway. Normally someone who wants to use pcc will either set CC=pcc manually or have it be their main cc/c99. > My main thought is that using > +test -z "$LIBCC" && tryldflag LIBCC `$CC -print-file-name=libpcc.a || true` > may be unnecessary; if -print-file-name=libpcc.a works, then there shouldn't be a need for more... > although pcc does have libpccsoftfloat.a as well. What does pcc do with -print-file-name=nonexistant.a? gcc does not give an error; it just prints the name without any path. So this would cause gcc to add libpcc.a to the command line if LIBCC is blank... > > - inline syscalls for microblaze > > - explicit mips soft-float abi support (mainly for use with broken > > openwrt kernels) > I'm guessing they disabled the FPU emulation for size: on a router, > a few kb can change whether you can (for example) add dropbear > instead of using Busybox telnetd; I happen to have one where they > couldn't. Yes; I suspect they could have found a way to get the space without breaking the ABI though... > On a related note, would it be possible to add "size of a static > busybox binary with a minimal config" (or a static dropbear, or some > other program frequently used for embedded systems) to the libc > comparison table? I'm thinking that may be the most meaningful > metric for people working on embedded systems. Yes, that's a very good idea. > > - make endian.h more robust for opposite-endian builds (mipsel, armeb) > > Don't forget microblazeel (a/k/a microblazele, for the linker) > The linker uses -mbig-endian/-mlittle-endian to select, IUIC. gcc should handle passing the right options to the linker for the target it's configured for... > > And a few other things that might make it in, if I get around to them: > > > > - subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.) > Perhaps x86-sse eventually? x86-sse is not a different ABI in the sense I'm talking about; the non-sse libc will work fine with apps that use sse, and sse libc will work fine with apps that don't, as long as the cpu supports sse. This is because the calling convention, alignments, etc. are all the same. An example of a different x86 abi would be using pass-by-register (fastcall) for everything (except possibly variadic functions) and passing floating point args/returns in sse registers. This would be a very interesting project, but I'm not sure GCC is up to the task. Rich