Subject: Re: 32 bit & 64 bit libraries.
To: None <,>
From: None <>
List: tech-toolchain
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
to do.