Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.