From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8882 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Support for out-of-tree build Date: Tue, 17 Nov 2015 17:01:41 -0500 Message-ID: <20151117220141.GD3818@brightrain.aerifal.cx> References: <20151112145026.GB18372@port70.net> <20151112203048.GB3818@brightrain.aerifal.cx> <20151112211024.GC18372@port70.net> <20151112215232.GC3818@brightrain.aerifal.cx> <20151112234137.GD3818@brightrain.aerifal.cx> <20151117210021.GB3818@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: ger.gmane.org 1447797718 18755 80.91.229.3 (17 Nov 2015 22:01:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 22:01:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8895-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 17 23:01:58 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZyoK5-0005w6-Bz for gllmg-musl@m.gmane.org; Tue, 17 Nov 2015 23:01:57 +0100 Original-Received: (qmail 24566 invoked by uid 550); 17 Nov 2015 22:01:54 -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 24548 invoked from network); 17 Nov 2015 22:01:54 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8882 Archived-At: On Tue, Nov 17, 2015 at 09:37:37PM +0000, Petr Hosek wrote: > How would you express the fact that e.g. armhf subarch should use armel > implementation of memcpy.s? The point of the *.sub files is to define a mapping from a fully specific subarch (with 'default'/'empty' replaced with an explicit default; this is why configure sets ASMSUBARCH=el for plain arm) to the actual file to use, which is almost always going ot be shared between a number of subarchs when there's more than one 'dimension' involved. However there's no need for this mapping to be defined per-file. In reality it's sufficient to have a fixed fallback sequence. In the rare case where there were asm files that depended on endianness and hard/soft float in the same file, the fallback order would look something like (for le-hf): le-hf le-any any-hf any-any But for our actual usage cases it suffices just to have: le hf any However, at this point I'm strongly considering whether we should just do away with the subarch dirs entirely and use preprocessed asm or C with inline asm in their place. The one place this is mildly difficult is when only some of the subarchs want the asm at all, and others want the generic C. This is common for fenv.s and also applies to arm memcpy.s where we lack a big-endian variant. One possible solution would be to have (for example) src/string/arm/memcpy.c that just does #ifdef __ARMEB__ #include <../memcpy.c> #endif and then put memcpy.S in arch/arm/src/ with #ifndef __ARMEB__ around the whole file. That would fully eliminate the subarch mess from the build system and leave us with a fixed fallback order for it to use: $(ARCH)/%.S $(ARCH)/%.s $(ARCH)/%.c %.S %.s %.c Currently the unadorned %.S/%.s is not needed, but I would consider adding it so we can put asm files in arch/$(ARCH)/src without needing dummy .c files for them to pull in asm from arch/$(ARCH)/src/$(ARCH). Would this make things simpler for the build system? I think so. Rich