[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121128192618.GA7491@brightrain.aerifal.cx>
Date: Wed, 28 Nov 2012 14:26:18 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Design idea for subarchs/abivariants
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.
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.
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.
Comments?
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.
