[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <520AE098.4010106@gentoo.org>
Date: Wed, 14 Aug 2013 03:42:48 +0200
From: Luca Barbato <lu_zero@...too.org>
To: musl@...ts.openwall.com
Subject: Re: Build system adjustments for subarchs
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
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.
