To: None <tech-toolchain@NetBSD.ORG>
From: Todd Vierling <firstname.lastname@example.org>
Date: 07/26/1998 14:26:19
The proposal I made for Jonathan's OBJ_ARCH idea has met with mild approval,
so let's see if I can clean it up a bit and make it clearer. Carbon copied
to the pkg folks and port-mips list, who will be affected by this. PLEASE
DIRECT REPLIES EITHER TO ME OR TECH-TOOLCHAIN; thanks.
For those who read the last one, there are a couple changes at the bottom.
Background: The mips platforms are using "mips" as the value for
MACHINE_ARCH on both little and big endian, 32-bit, platforms thus far,
rendering MACHINE_ARCH useless as a unique binary compatibility identifier.
Fortunately, this will not break with 1.3.x releases as newsmips has no
Define MACHINE_OBJ_ARCH as an identifier that specifies a unique set of CPU,
architecture, and toolchain criteria from the _default_ output of the
- the processor architecture, such as mips or m68k
- the object file format (a.out, ELF32, ELF64, ECOFF)
- the least common denominator processor (for example, m68k = MC68020)
- the endianness of the processor, if it supports multiple endiannesses
- the basic set of integer and pointer sizes
With that defined, here's how I propose MACHINE_OBJ_ARCH be implemented:
- MACHINE_OBJ_ARCH will be the identifier used in NetBSD documentation to
describe the type of binaries used on a given system, unless the binaries
are machine-specific. (This proposal is intended to make machines of a
MACHINE_OBJ_ARCH share release sets as well, excepting kernel.)
- 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 before
- A machine may be capable of running binaries for more than one
MACHINE_OBJ_ARCH just like any other COMPAT_ emulation, with a correctly
populated /emul tree. There is no provision for hard-coding a list of
emulated MACHINE_OBJ_ARCHs, though there may be compatibility pkgs made
for them. (Example: running 32-bit binaries on a 64-bit system.)
- A change in the MACHINE_OBJ_ARCH will happen when a new architecture
intrinsic (binary format, endianness, integer/pointer size) is introduced
in a new port but the MACHINE_ARCH is still the same.
- When a new MACHINE_OBJ_ARCH is created, the different port will use a new
MACHINE_OBJ_ARCH, but the old MACHINE_OBJ_ARCH will _not_ change its name
to look aesthetically similar.
- The value will be available for scripts to choose the proper architecture
via "sysctl hw.obj_arch" and "uname -o". (This is the reason for the
previous condition: it must remain the same as long as the object format
remains the same.)
- NetBSD's make (Pmake) program will include a definition of
MACHINE_OBJ_ARCH such that NetBSD builds may use it in Makefiles directly.
- All machines in the same MACHINE_OBJ_ARCH will use an identical toolchain.
However, the toolchain may contain alternate build targets or binary
format conversion tools useful only for some of the machines in a
- GNU autoconf changes:
* Each MACHINE_OBJ_ARCH will have a corresponding MACHINE_GNU_ARCH,
a one-to-one mapping to ensure uniqueness, useable in the rules below.
For the most part, these are the same.
* Configure scripts will accept MACHINE_GNU_ARCH*-*-netbsd as a valid
identifier for a given OBJ_ARCH. No script should depend on the
"manufacturer" field to define any architecture intrinsics.
(Exception: GNU autoconf scripts will remap mips-dec-netbsd to
mipsel-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
- NetBSD Foundation released binaries bearing the MACHINE_OBJ_ARCH tag will
conform to the least common denominator processor for that
MACHINE_OBJ_ARCH, using the default toolchain output.
- A toolchain format change, such as a.out->ELF, requires a change of
MACHINE_OBJ_ARCH, as compatibility requires the appropriate shared loader
and shared libraries.
- The ONLY_FOR_ARCHS rule in pkg Makefiles will continue to use
MACHINE_ARCH, and not MACHINE_OBJ_ARCH.
- For pkg system compatibility, MACHINE_OBJ_ARCH will be the same as
MACHINE_ARCH for 1.3.x systems by checking whether or not Pmake sets the
MACHINE_OBJ_ARCH variable. That means that pmax is "mips" for 1.3.x pkgs,
and "mipsel" for 1.4+ pkgs.
-- Todd Vierling (Personal email@example.com; Bus. firstname.lastname@example.org)