From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2346 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 0.9.8 released Date: Tue, 27 Nov 2012 20:51:16 -0800 Message-ID: <20121127205116.1dbf130f.idunham@lavabit.com> References: <20121127024958.GA23123@brightrain.aerifal.cx> <20121127184329.a20d1160.idunham@lavabit.com> <20121128033948.GO20323@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: ger.gmane.org 1354078294 20147 80.91.229.3 (28 Nov 2012 04:51:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2012 04:51:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2347-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 28 05:51:46 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 1TdZcc-0000MY-BD for gllmg-musl@plane.gmane.org; Wed, 28 Nov 2012 05:51:42 +0100 Original-Received: (qmail 31750 invoked by uid 550); 28 Nov 2012 04:51:31 -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 30718 invoked from network); 28 Nov 2012 04:51:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=QqKxzLtW9PruCyJQUSaXjY04Nh6wTWoGdy4ZtWu3GqV+GkO/TSB8RD9YIayMTErQVeDHlGOZTSU5IXcInHBQl1ur7Z6XGapmFM2h9b2ueXr2aroVqwsB5I6a+rxBIFAR5W4TDgaEPBoX+1tDU8snvS/5PAPRUlcblICM/8CZ3D0=; h=Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <20121128033948.GO20323@brightrain.aerifal.cx> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:2346 Archived-At: On Tue, 27 Nov 2012 22:39:48 -0500 Rich Felker wrote: > On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote: > > arm: arm(eb), armel > > mips: mips(32), mipsel(32) > > microblaze: microblaze > > (What's the status of microblazeel/microblazele? configure looks not > > to recognize it...) > > It should work aside from configure not recognizing it. But I don't > think it's been tested. > > > ppc: powerpc(32) > > > > Total arches: > > 6 > > Total subarches (distinct ABIs): > > 8-10 (depending on status of microblazeel and ABI compatability of > > armhf with armel) > > > > -planned subarches: mipsel32-sf, mips32-sf > > My idea for the names would be something like: mips, mipsel, mips-sf, > mipsel-sf, ... > Basically, the full arch name would be something along the lines of: > > arch[el|eb][-abivariant] > > which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where > only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for > asm files. But additional considerations need to be made for how the > main arch dir with bits headers and internal headers would be > selected. I don't think we want to duplicate entire arch trees for > subarchs, but I also don't see how subarchs can get by with using the > same set of headers unless we rely on the compiler to predefine macros > that distinguish them. This is rather ugly but we're already partially > relying on it for endianness varants. Where would the headers need to differ by subarch? I'm guessing this is mainly stuff like fenv? > In the end, it might simply be the cleanest to just duplicate the > trees, but use symlinks to eliminate most of the duplicate files. > However, the interaction of that with install rules would have to be > considered and the install rules might need revision. > > -unsupported subarches: i386 > > ?? The 80386 processor, as opposed to 80486. # On x86, make sure we don't have incompatible instruction set # extensions enabled by default. This is bad for making static binaries. # We cheat and use i486 rather than i386 because i386 really does not # work anyway (issues with atomic ops). Also, I can't seem to find it now, but somewhere I heard that upstream gcc and/or glibc with the "i386-linux-*" triplet has some incompatability with "i486-linux-*". IIRC, I heard that some distros patch this to treat i386-linux-* as if it meant i486. But, I can't trace the source for that claim, so don't count on it... > > It seems Debian's using aarch64-* for ARMv8. > > Yes, 64-bit arm is a new arch and it seems they used the name aarch64 > instead of arm64 due to arm* being interpreted as 32-bit arm by many > things.. > ie, due to the insane number of ABIs and triplets that ARM has? arm (bigendian/OABI), armeabi (bigendian: armeb), armel (littleendian variant of EABI), armhf (armel + vfp3) -- Isaac Dunham