Subject: Re: poor error reporting when ld.so is missing
To: None <p99dreyf@criens.u-psud.fr, woods@weird.com>
From: None <eeh@netbsd.org>
List: tech-kern
Date: 04/16/2001 21:29:13
	2) libc's exec() fires the exec() system call, with the name of the
	binary to execute as the argument.

	3) exec calls various function to discover how to run the program. Is it
	NetBSD ELF, NetBSD a.out, Linux ELF, FreeBSD a.out?

	4) For dynamically linked executables, theses test functions check that
	the interpreter (ld.so) exist. For ELF programs, the interpreter name is
	taken from the .interp ELF section. I don't know how it works for a.out.

	5) If the interpreter exists, then the program is matched for the given
	architecture. otherwise, the test fails, and the kernel proceed for the
	next test (eg: it's not a Linux binary, let's try FreeBSD)

The problem is:

The location of the interpreter is relative to the emulation's root,
so the non existance of `/usr/lib/foo' does not imply the non existance
of `/emul/foo/usr/lib/foo'.

It is sometimes not possible to determine directly from the executable
image what type it is, espcecially ELF binaries that don't have notes
specifying the operating system.

Because of that, failure of one exec package does not mean that another
exec package will also fail.

Eduardo