Subject: MACHINE_ARCH vs. OBJ_ARCH
To: None <tech-toolchain@NetBSD.ORG>
From: Todd Vierling <firstname.lastname@example.org>
Date: 07/25/1998 23:47:29
In the interest of trying on another's shoes, I'll propose Jonathan's own
alternate solution, OBJ_ARCH, with all extra bases covered. Please respond
with any comments. Yes, this means I'm volunteering to do a significant
chunk of said work, but it's really not as difficult as it looks.
Define OBJ_ARCH as an identifier that specifies a unique set of CPU,
architecture, and toolchain criteria:
- the processor architecture, such as mips or m68k
- the basic object file format (a.out, ELF32, ELF64, ECOFF) that is the
_default_ output of the toolchain for that OBJ_ARCH
- the least common denominator processor, which is also the default output
of the toolchain (for example, m68k = MC68020)
- the endianness of the processor, if it supports multiple endiannesses
- the basic set of integer and pointer sizes uniform across the OBJ_ARCH
With that defined, here's how I propose OBJ_ARCH be implemented:
- Unless otherwise changed, it will be equal to the current value of
MACHINE_ARCH. This is in the interest of simplicity.
Exceptions: mips splits into mipseb and mipsel, and the sparc64 port
becomes sparc64 if it changes to a native 64-bit object format.
- A change in the OBJ_ARCH will happen when a new architecture intrinsic
(endianness, integer/pointer size) is introduced in a new port.
- When a new OBJ_ARCH is created, the new port will use a new OBJ_ARCH but
the old OBJ_ARCH will _not_ change its name to match aesthetically.
- The value will be available for scripts to choose the proper architecture
via "sysctl hw.obj_arch". (This is the reason for the previous
- NetBSD's make (Pmake) program will include a definition of OBJ_ARCH such
that NetBSD builds may use it in Makefiles directly.
- All machines in the same OBJ_ARCH will use an identical toolchain, even
though alternate object format targets may be available for kernel or
other special purpose builds on some ports in an OBJ_ARCH.
- GNU autoconf scripts will be modified such that:
* Each OBJ_ARCH has a one-to-one mapped MACHINE_GNU_ARCH which can be used
in configuration as MACHINE_GNU_ARCH-unknown-netbsd. No script will
depend on filling in the "manufacturer" field. (Already have
MACHINE_GNU_ARCH, but it's not unique for mips.)
* GNU autoconf scripts will remap mips-dec-netbsd to mipsel-unknown-netbsd
and mips-sony-netbsd to mipseb-unknown-netbsd for compatibility.
* These GNU autoconf changes will be applied to the NetBSD source in-tree
(src/gnu/dist) as well as GNU pkgs, and appropriate code changes for
autoconf will be sent back to the FSF for inclusion in the next autoconf
- Release sets and binary packages will use OBJ_ARCH to identify a set of
compatible binaries. Released binaries bearing the OBJ_ARCH tag will
conform to the least common denominator processor, though anyone is of
course free to make binaries that are customized for a "higher" processor.
- If a toolchain change happens to only _part_ of an OBJ_ARCH between full
formal releases, such as a.out->ELF, the new toolchain becomes a new
OBJ_ARCH (and again, the old name stays the same). HOWEVER, if the entire
OBJ_ARCH changes toolchains between full formal releases, the OBJ_ARCH
need not change, as it is still unique combined with the NetBSD version.
- For pkg system compatibility, OBJ_ARCH will be the same as MACHINE_ARCH
for 1.3.x systems by checking whether or not Pmake sets the OBJ_ARCH
variable; except for "mips", which will become the new "mipsel", as only
little-endian mips platforms had 1.3.x releases.
-- Todd Vierling (Personal email@example.com; Bus. firstname.lastname@example.org)