Re: Design idea for subarchs/abivariants

[John Spencer <maillist-musl@barfooze.de>]

On 11/28/2012 08:26 PM, Rich Felker wrote:
> The problem: how to have subarch variants on the bits headers and asm
> for a given arch without ugly build system complications or massive
> duplication of files.
>
> Proposed solution:
>
> 1. $(ARCH)$(SUBARCH)/%.s is searched in addition to $(ARCH)/%.s for
> arch-specific files replacing general %.c files in the src tree. This
> would allow src/fenv/arm-hf/%.s and src/setjmp/mips-sf/%.s files, for
> example.
that sounds good.
> 2. Making bits/endian.h, bits/fenv.h, and any other bits headers that
> need to vary per-subarch into generated headers. I think this could be
> accomplished with a single rule for generating bits/%.h from
> bits/%.h.sh the way alltypes.h is generated now. The full
> $(ARCH)$(ENDIAN)$(SUBARCH) could be passed to the script as $1,
> allowing simple shell logic to choose the right version to output.
as for endian, the current way seems to work well. we can rely on what 
gcc provides
(even if it doesnt supply the endianness directly, it has something like 
__mipsel__ set,
which we currently already use).
and apart from endian.h, there doesn't seem to be any
need for endian-specific code.
> 3. Having configure derive separate $(ARCH), $(ENDIAN), and $(SUBARCH)
> from the gcc-style machine strings or combined musl-format arch string.
>
> This sounds like it will be minimally invasive and meet the
> requirements for supporting subarch/abi-variants.
as long as it works automatically (i.e. by querying gcc), cool.
but having to pass something like --target=musl-armeabi-v4-el oslt is ugly.