From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2345 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 0.9.8 released Date: Tue, 27 Nov 2012 22:39:48 -0500 Message-ID: <20121128033948.GO20323@brightrain.aerifal.cx> References: <20121127024958.GA23123@brightrain.aerifal.cx> <20121127184329.a20d1160.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 1354074001 23774 80.91.229.3 (28 Nov 2012 03:40:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2012 03:40:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2346-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 28 04:40:14 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 1TdYVR-00030z-7g for gllmg-musl@plane.gmane.org; Wed, 28 Nov 2012 04:40:13 +0100 Original-Received: (qmail 32051 invoked by uid 550); 28 Nov 2012 03:40:01 -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 32043 invoked from network); 28 Nov 2012 03:40:01 -0000 Content-Disposition: inline In-Reply-To: <20121127184329.a20d1160.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2345 Archived-At: On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote: > All very good, and I don't think I've got any more to add... > > So I guess that leaves the subarches like so: > x86: i486, x86_64 i386 and x86_64 aren't subarchs of a common arch. They're completely independent ISAs and cannot share any code. > 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. 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. > -planned arches: x32 Yes. I think x32 (and mipsn32) probably need to be considered as separate archs, despite being the same ISAs as x86_64 (and mips64). > -distant: mips64, mipsel64, ppc64 (I *think* Rich Pennington got > these working, but they haven't been merged) Well, for a very limited definition of working. A majority of the actual *code* is done, but the headers were basically all just copies of the arm headers, meaning not much actually works. > -unsupported subarches: i386 ?? > 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.. Rich