Subject: MACHINE_ARCH vs. OBJ_ARCH
To: None <tech-toolchain@NetBSD.ORG>
From: Todd Vierling <tv@pobox.com>
List: tech-toolchain
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
  condition.)

- 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.

- 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 tv@pobox.com; Bus. todd_vierling@xn.xerox.com)