Subject: Re: 32 bit & 64 bit libraries.
To: None <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 08/13/2001 11:30:39
On 13 Aug 2001 email@example.com wrote:
: | Fine to me, except that we should use the NetBSD names for the
: | MACHINE_ARCH for consistency on NetBSD. We don't have any other direct
: | references to "sparcv9", for instance; this should be "sparc64". (Although,
: | if the sparc64 default userland is 64-bit, there won't be a -sparc64
: | version, just a -sparc 32-bit version. 8-)
: No, I think we should use the architecture-specific name for the binary
: format. In this case it would be possible to generate a full set of
: sparcv8plus binaries, which are 32-bit, but use v9 instructions and would
: thus be incompatible with the standard sparcv8 binary format.
v8plus is still a v7/v8-compatible binary format which Happens To Use V9
Instructions; thus it *could* use the v7 compiled ld.elf_so and libc, right?
Compiling a v8plus userland as a one-off option doesn't negate this
assertion. You could make a similar analogy to m68k; the 68040 has a wealth
more instructions than the 68020, but it's still the same binary format and
Thus, a 32-bit dynamic linker and libc on a 64-bit native userland should be
called "sparc" to match our MACHINE_ARCH name; not "sparcv8".
: MIPS illustrates this issue quite well. Ignoring the inverse-endian issues,
: mips has at least O32, N32, and N64 binary formats, if not more. All these
: formats are mutually incompatible.
And are separate MACHINE_ARCHs to us, were we to implement all these code
-- Todd Vierling <firstname.lastname@example.org> * Wasabi NetBSD: Run with it.
-- NetBSD 1.5 now available on CD-ROM -- http://www.wasabisystems.com/