Hi All,
Regarding the recent threads on app-tools naming, et al. I'd like to get
some advice from knowledgeable toolchain people before making a final
choice. I have written the following draft to send to the GCC mailing list
as that appears to be where most toolchain people hang out.
Antti, Justin, anyone else interested, can you please read through this and
let me know if its clear and if I have missed anything before I send it on
to the GCC folks?
Thanks,
Martin
---------------------------------------------------
Subject: Choosing an architecture tuple for Rumprun
Hi All,
I'm working on improving the toolchain for the Rumprun stack, and need to
decide on a suitable architecture tuple to use both as a prefix for naming
the toolchain and to pass to autoconf/other build systems when building
applications.
Background: Rumprun[1] is a software stack built with Rump Kernels[2] which
enables running existing POSIX software without an operating system on
various platforms (Xen, bare metal/QEMU/KVM, POSIX userspace).
Our toolchain is somewhat special in that we don't currently build a cross
compiler from scratch, but instead generate wrappers and GCC spec files
which allow us to re-use an existing (cross-)compiler installed on the
build system.
My goals with naming are the following, in rough order of "must have"
priority:
a) come up with a tuple that is as backwards-compatible as possible with
*existing, unmodified* build systems. I.e. any software that has
existing support for cross-compiling in its build system should "just
build". Note that I'm not expecting all software thus built to "just
work", as that is out of the scope of the build system.
b) ensure the naming scheme is extensible for future ISA, platform (see
below) or ABI combinations we've not yet thought of.
c) if possible, facilitate installing several toolchains for different
platforms side by side without needing to use separate directory
hierarchies. This is primarily for end-user convenience once we provide
installable packages of the rumprun stack.
d) there are some very specific software packages (Xen libraries, QEMU)
that may wish to use "private" interfaces provided by the underlying
platform rumprun is running on. It is unclear if this is best done by
compile-time testing for the presence of such interfaces, or if we
should provide information about the underlying platform to the
application build system, ie. make it visible in the chosen architecture
tuple.
I have the following two proposals:
1) Use the "Old form"[3] cpu-vendor-os:
'cpu' would be the target ISA (arm, i386, x86_64, ...).
'vendor' would be 'rumprun'.
'os' would be 'netbsd', as we provide a NetBSD-ish "userspace".
Thus, a toolchain would be installed as eg.
i386-rumprun-netbsd-{gcc,g++,...} and the autoconf tuple would be
i386-rumprun-netbsd.
2) Use the "New form"[3] cpu-vendor-kernel-os:
'cpu' would be the target ISA (arm, i386, x86_64, ...).
'vendor' would be 'rumprun'.
'kernel' would be the underlying platform that rumprun is running on,
i.e. 'xen', 'baremetal', 'posix', 'kvm', ...
'os' would be 'netbsd', as we provide a NetBSD-ish "userspace".
Thus, a Xen toolchain would be installed as eg.
i386-rumprun-xen-netbsd-{gcc,g++,...} and the autoconf tuple would be
i386-rumprun-xen-netbsd.
Proposal 1) fulfills goals a), possibly b) but not c) or d).
Proposal 2) fulfills goals b), c) and d) but not a) due to requiring an
update to upstream config.sub files everywhere.
Further, even though this is bad practice, I have seen configure scripts
make decisions based on a list of hard-coded "os" names, in this case
"netbsd" is what we want such scripts to believe since our "userland" is
essentially NetBSD libc/libc++. This would appear to be another argument in
favour of proposal 1) above.
Any advice on choosing which way to proceed will be much appreciated.
One last thing I don't fully understand is whether or not we need to care
about ABI differences for embedded systems (eg. hard vs soft float) for the
purposes of the rumprun toolchain.
Thanks,
Martin
[1] http://repo.rumpkernel.org/rumprun
[2] http://rumpkernel.org/
[3] As documented in the comments at the start of 'config.sub':
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
