From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8883 Path: news.gmane.org!not-for-mail From: Petr Hosek Newsgroups: gmane.linux.lib.musl.general Subject: Re: Support for out-of-tree build Date: Tue, 17 Nov 2015 22:15:29 +0000 Message-ID: References: <20151112145026.GB18372@port70.net> <20151112203048.GB3818@brightrain.aerifal.cx> <20151112211024.GC18372@port70.net> <20151112215232.GC3818@brightrain.aerifal.cx> <20151112234137.GD3818@brightrain.aerifal.cx> <20151117210021.GB3818@brightrain.aerifal.cx> <20151117220141.GD3818@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c07eaa09fa3b10524c3ddae X-Trace: ger.gmane.org 1447798563 32119 80.91.229.3 (17 Nov 2015 22:16:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 22:16:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8896-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 17 23:15:57 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZyoXb-0001BO-7Q for gllmg-musl@m.gmane.org; Tue, 17 Nov 2015 23:15:55 +0100 Original-Received: (qmail 14093 invoked by uid 550); 17 Nov 2015 22:15:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14066 invoked from network); 17 Nov 2015 22:15:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=xLXinZzrmzwDgptOYvXJZ9Di1UPRY7Ka576m92Vo2Mg=; b=El0dIaa5xJaQdrZ/iwFljm8VEZH7/HVHPXM0zrFBTflTJrYeh36rZBc18DCea3dW/I yjQzdcRklpaX1iVUGZhTkU75nxF2fu5r/77hra0grZfI5IuwmQ1FAlKvZ25gf6w/FbEw ojiRYUR9zhwzyyatjJ+NqjZKFHd+kHH6/c6gE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=xLXinZzrmzwDgptOYvXJZ9Di1UPRY7Ka576m92Vo2Mg=; b=lmufrOg7FNdwaesaW5cOknXQH3z5wjJKkiw/1G30zRB05NsuPh2eXnl7vOYJBWFvSU FIx00UnTZic5zFChHl0hiwxbVM2p8iRVBk9HBxYZZGq0E/0chRagTVv/bolV1K1g8EIB gGdaTCWmzN5Ohh5JHDTa2r0lyCjzzJMnw8NeLYRTAedtKj/S4IAL0icuZzdN4vyFzfH7 rFw/wrYG5iv/ad6wilvIcOP0AEerP17/FWvqBBs5Unh2uWdPi/xYYYOvmqb9336dX2wi K/J5JRq2c1VAuLnv3jNO8mgD7HJBGL2HkRYjLIiVAo6Oq45mFgIvKvuIUlhK+JwsfThR tQcw== X-Gm-Message-State: ALoCoQmk4ynFgzv9KXuDtITcWjDqtv+1PP96KA9/O2SCiNT6AT8SxWAk0TCDnUg6+Q/GmJ4l4mcM X-Received: by 10.13.218.68 with SMTP id c65mr41013784ywe.315.1447798538981; Tue, 17 Nov 2015 14:15:38 -0800 (PST) In-Reply-To: <20151117220141.GD3818@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8883 Archived-At: --94eb2c07eaa09fa3b10524c3ddae Content-Type: text/plain; charset=UTF-8 Absolutely, that's probably the simplest solution in the sense that it avoids using additional .mk/.sub files or complicated build-time logic. If that's the solution we all agree on, I'd be happy to implement this as a separate patch and then rebase the out-of-tree build patch on top of that. On Tue, Nov 17, 2015 at 2:01 PM Rich Felker wrote: > On Tue, Nov 17, 2015 at 09:37:37PM +0000, Petr Hosek wrote: > > How would you express the fact that e.g. armhf subarch should use armel > > implementation of memcpy.s? > > The point of the *.sub files is to define a mapping from a fully > specific subarch (with 'default'/'empty' replaced with an explicit > default; this is why configure sets ASMSUBARCH=el for plain arm) to > the actual file to use, which is almost always going ot be shared > between a number of subarchs when there's more than one 'dimension' > involved. > > However there's no need for this mapping to be defined per-file. In > reality it's sufficient to have a fixed fallback sequence. In the rare > case where there were asm files that depended on endianness and > hard/soft float in the same file, the fallback order would look > something like (for le-hf): > > le-hf le-any any-hf any-any > > But for our actual usage cases it suffices just to have: > > le hf any > > However, at this point I'm strongly considering whether we should just > do away with the subarch dirs entirely and use preprocessed asm or C > with inline asm in their place. The one place this is mildly difficult > is when only some of the subarchs want the asm at all, and others want > the generic C. This is common for fenv.s and also applies to arm > memcpy.s where we lack a big-endian variant. > > One possible solution would be to have (for example) > src/string/arm/memcpy.c that just does > > #ifdef __ARMEB__ > #include <../memcpy.c> > #endif > > and then put memcpy.S in arch/arm/src/ with #ifndef __ARMEB__ around > the whole file. > > That would fully eliminate the subarch mess from the build system and > leave us with a fixed fallback order for it to use: > > $(ARCH)/%.S > $(ARCH)/%.s > $(ARCH)/%.c > %.S > %.s > %.c > > Currently the unadorned %.S/%.s is not needed, but I would consider > adding it so we can put asm files in arch/$(ARCH)/src without needing > dummy .c files for them to pull in asm from arch/$(ARCH)/src/$(ARCH). > > Would this make things simpler for the build system? I think so. > > Rich > --94eb2c07eaa09fa3b10524c3ddae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Absolutely, that's probably the simplest solution in t= he sense that it avoids using additional .mk/.sub files or complicated buil= d-time logic.

If that's the solution we all agree on= , I'd be happy to implement this as a separate patch and then rebase th= e out-of-tree build patch on top of that.

On Tue, Nov 17, 2015 at 2:01 PM Rich Felker <dalias@libc.org> wrote:
On Tue, Nov 17, 2015 at 09:37:37PM +0000, Petr Hose= k wrote:
> How would you express the fact that e.g. armhf subarch should use arme= l
> implementation of memcpy.s?

The point of the *.sub files is to define a mapping from a fully
specific subarch (with 'default'/'empty' replaced with an e= xplicit
default; this is why configure sets ASMSUBARCH=3Del for plain arm) to
the actual file to use, which is almost always going ot be shared
between a number of subarchs when there's more than one 'dimension&= #39;
involved.

However there's no need for this mapping to be defined per-file. In
reality it's sufficient to have a fixed fallback sequence. In the rare<= br> case where there were asm files that depended on endianness and
hard/soft float in the same file, the fallback order would look
something like (for le-hf):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 le-hf le-any any-hf any-any

But for our actual usage cases it suffices just to have:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 le hf any

However, at this point I'm strongly considering whether we should just<= br> do away with the subarch dirs entirely and use preprocessed asm or C
with inline asm in their place. The one place this is mildly difficult
is when only some of the subarchs want the asm at all, and others want
the generic C. This is common for fenv.s and also applies to arm
memcpy.s where we lack a big-endian variant.

One possible solution would be to have (for example)
src/string/arm/memcpy.c that just does

#ifdef __ARMEB__
#include <../memcpy.c>
#endif

and then put memcpy.S in arch/arm/src/ with #ifndef __ARMEB__ around
the whole file.

That would fully eliminate the subarch mess from the build system and
leave us with a fixed fallback order for it to use:

$(ARCH)/%.S
$(ARCH)/%.s
$(ARCH)/%.c
%.S
%.s
%.c

Currently the unadorned %.S/%.s is not needed, but I would consider
adding it so we can put asm files in arch/$(ARCH)/src without needing
dummy .c files for them to pull in asm from arch/$(ARCH)/src/$(ARCH).

Would this make things simpler for the build system? I think so.

Rich
--94eb2c07eaa09fa3b10524c3ddae--