From: Luca Barbato <lu_zero@gentoo.org>
To: musl@lists.openwall.com
Subject: Re: Build system adjustments for subarchs
Date: Wed, 14 Aug 2013 03:42:48 +0200 [thread overview]
Message-ID: <520AE098.4010106@gentoo.org> (raw)
In-Reply-To: <20130814010617.GA16011@brightrain.aerifal.cx>
On 14/08/13 03:06, Rich Felker wrote:
> 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).
> - armel/%.s and armhf/%.s as duplicate files or symlinked
> - armhf/%.s and armebhf/%.s as duplicate files or symlinked
I'd just explicitly group files by the most selective so
ARMEL+=${list of objects that work on el doesn't matter what}
ARMHF+=${list of objects that work on hf doesn't matter what}
ARMEB+=${list of objects that work on eb doesn't matter what}
ARMHFEL+=$(ARMEL) $(ARMHF) ${other stuff}
ARMHFEB+=$(ARMEB) $(ARMHF) ${different stuff}
OBJS+=$($(targetarch))
And give up on having automagic fallbacks.
lu
next prev parent reply other threads:[~2013-08-14 1:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 1:06 Rich Felker
2013-08-14 1:16 ` Rich Felker
2013-08-14 1:42 ` Luca Barbato [this message]
2013-08-14 1:53 ` Rich Felker
2013-08-14 2:25 ` Rich Felker
2013-08-14 3:42 ` Rich Felker
2013-08-14 4:02 ` Rich Felker
2013-08-14 15:09 ` Szabolcs Nagy
2013-08-14 15:15 ` Rich Felker
2013-08-14 15:28 ` Luca Barbato
2013-08-15 0:55 ` Strake
2013-08-15 1:48 ` Rich Felker
2013-08-15 12:33 ` Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520AE098.4010106@gentoo.org \
--to=lu_zero@gentoo.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).