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

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

: This way the default libraries would still be in /usr/lib, and multiple
: sub-arches can coexist on one system. The only downpoint is that there
: may be a mismatch between the loader stored in the ELF header and the
: one actually run, if the kernel picks the -<arch> one for a native binary.

If you do an -<arch> transform on only the ELF interpreter string if it
exactly matches "/usr/libexec/ld.elf_so", this shouldn't be too much an
issue.  If the user specifically asked for a different interpreter binary,
we can't be sure what was desired, and should use it as-is.

FWIW, "ld.elf_so-<arch>" looks a little inconsistent visually; perhaps `.'
instead of `-'?  ("ld.elf_so.<arch>")

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/