Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.