Date: Tue, 17 Nov 2015 17:01:41 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Support for out-of-tree build 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
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.