Subject: Re: 32 bit & 64 bit libraries.
To: None <firstname.lastname@example.org, email@example.com>
From: None <firstname.lastname@example.org>
Date: 08/13/2001 15:08:37
| On Mon, 13 Aug 2001, Frank van der Linden wrote:
| : * For NetBSD binaries, if the loader is "/usr/libexec/ld.elf_so",
| : have the kernel look at <loader>-<arch> first, and if this
| : doesn't exist it uses <loader>. I.e. in the standard case it
| : tries /usr/libexec/ld.elf_so-sparcv9 first for a 64 bit binary,
| : if this doesn't exist it uses /usr/libexec/ld.elf_so. <arch>
| : here is the architecture that
| : matches the type in the ELF header (i.e. sparc or sparcv9 or
| : ia64 or i386 etc)
| 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.
| : * ld.elf_so looks in /usr/lib/<arch> before /usr/lib (where <arch>
| : is the type of binaries it's supposed to handle, not the
| : system that it runs on).
| Also fine. I can see this as useful for the hypothetical (but proposed many
| times) inverted-endian MIPS emulation....
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. If we were to use `mipsel32' and `mipsbe64',
we would be limited to only 4 of those formats, which I don't think we want