From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3887 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Build system adjustments for subarchs Date: Tue, 13 Aug 2013 21:06:17 -0400 Message-ID: <20130814010617.GA16011@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 1376442389 24703 80.91.229.3 (14 Aug 2013 01:06:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Aug 2013 01:06:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3891-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 14 03:06:31 2013 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 1V9PXi-0003VV-Qh for gllmg-musl@plane.gmane.org; Wed, 14 Aug 2013 03:06:30 +0200 Original-Received: (qmail 17970 invoked by uid 550); 14 Aug 2013 01:06:30 -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 17962 invoked from network); 14 Aug 2013 01:06:29 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3887 Archived-At: Hi, I'm looking for some ideas on a problem in the build system: how to cleanly share asm between subarchs. The problem is this: ARM, and possibly other archs in the future, has multiple dimensions of subarch: little-endian(default) vs big-endian, and fpu-agnostic(default) vs hardfloat. The asm requirements are: - MOST asm is shared by all subarchs. - A small amount of asm (for now, just memcpy) is endian-specific but has nothing to do with floating point ABI. - A fairly significant amount of asm in the future will be hard-float specific (optimized math functions and floating point environment) but has nothing to do with endianness. Until commit 90d77722511ad5e9b748f69f42c5b2a8467fa049, asm was shared by all subarchs; there was no ability to have subarch-specific overrides. At least one person (I can't remember who right off) suggested that instead of more build system logic, we should switch to preprocessed asm files (.S) so that a single asm file could include the logic to support all subarchs, but that was not a viable solution, because what I needed was a way to write asm for one subarch that doesn't interfere with the fallback C source file getting used for other subarchs. The current system searches for arch-specific asm in this order: 1. $(ARCH)$(ASMSUBARCH)/%.s, where ASMSUBARCH for the default subarch is not blank but rather a unique suffix (for plain arm, it's "el"). This allows having asm that applies only to the default subarch but not others. 2. $(ARCH)/%.s, for shared asm used by all subarchs. 3. %.c, the C fallback (which is empty for code that cannot be implemented at all in C). Unfortunately, this still provides no way to include asm that's used by both soft and hardfloat little-endian, or both little- and big-endian hardfloat, without having, for example: - armel/%.s and armhf/%.s as duplicate files or symlinked - armhf/%.s and armebhf/%.s as duplicate files or symlinked Duplicating code is ugly, and from what I've gathered, symlinks in git repos are frowned upon. (They don't work at all on Windows, even modern Windows versions that have symlinks, nor do they work on Android if your source tree is on a FAT32-formatted SD card). So, I'm looking for a better solution. One idea is to replace ASMSUBARCH with 3 different variables, and the makefile rules with 3 rules, allowing a fallback order of: 1. Matches in both dimensions 2. Matches in dimension 1 3. Matches in dimension 2 4. Generic asm for the arch 5. Default C code What I don't like about this approach is that the logic for the names to use in steps 1-3 has to go either in the configure script or the makefile. The makefile is not intended to have this sort of arch logic, but instead to derive the logic from the source tree structure. The configure script is intended to have some arch logic, but it should remain practical to use a hand-generated config.mak file, which becomes more burdensome if you have to define multiple arcane subarch vars. Another idea, using the filesystem, would be to have .sub files in the asm directories containing the filename of a different asm file to substitute. This is essentially emulating symlinks, but I don't see a good way to get make to do automated dependency tracking so that modifying the pointed-to asm file causes the object file to be rebuilt. I am exploring this approach further however in hopes that there might be a way. Any other ideas? Rich