mailing list of musl libc
 help / color / mirror / code / Atom feed
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






  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).