[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Nov 2012 21:26:43 +0100
From: John Spencer <maillist-musl@...fooze.de>
To: musl@...ts.openwall.com
Subject: Re: Design idea for subarchs/abivariants
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.
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.
