Re: Support for out-of-tree build

[Rich Felker <dalias@libc.org>]

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