[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130814010617.GA16011@brightrain.aerifal.cx>
Date: Tue, 13 Aug 2013 21:06:17 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Build system adjustments for subarchs
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
