Subject: Re: MACHINE_ARCH vs. OBJ_ARCH
To: None <tech-toolchain@NetBSD.ORG>
From: Perry E. Metzger <email@example.com>
Date: 07/26/1998 13:54:12
My only request: whatever gets decided on MUST BE CLEARLY DOCUMENTED.
Todd Vierling writes:
> 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 firstname.lastname@example.org; Bus. email@example.com)