From owner-freebsd-hackers Tue Oct 15 12:06:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA00723 for hackers-outgoing; Tue, 15 Oct 1996 12:06:44 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA00715; Tue, 15 Oct 1996 12:06:41 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01321; Tue, 15 Oct 1996 12:06:01 -0700 From: Terry Lambert Message-Id: <199610151906.MAA01321@phaeton.artisoft.com> Subject: Re: Linux compat issue(s) To: sos@FreeBSD.org Date: Tue, 15 Oct 1996 12:06:01 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.org In-Reply-To: <199610150933.LAA13406@ra.dkuug.dk> from "sos@FreeBSD.org" at Oct 15, 96 11:33:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Should I assume that this is the "what static ELF binary is this" problem? > > Exactly, the static ELF program is run as a FreeBSD native bin, there > is no way to know better (yet). > I guess we'll have to provide a solution for this shortcoming in > ELF (WHO said ELF was "the way to go" *sigh*) > I can do a "quick&dirty"(tm) little program that marks ELF bins so that > we can distinguish them, but it breaks the ELF std. one way or another. With respect, Linux distinguished the SVR4 vs. Linux ELF binaries. It does this by looking for the ld.so reference (which it always includes so it can use dlopen/etc.) and seeing the word "linux" in the ld.so file name reference. I think they also look at the crt0 startup code in the static binary case. This is actually broken. If you read the SVR4_EABI spec, there is a large area before the first page mapping for the program start. Page 0 is reserved, since SVR4 typically maps the page instead of faulting on reference (UnixWare 2.x has an undocumented kernel configuration ption to cause page zero references to always fault -- bet you didn't know that). Pages after 0 and before the program start are for mapping the ld.so. The mapping is expected to be established by the kernel -- *NOT* by the crt0.o. The difference is "more than enough" space -- one of those idiotic hard-coded "magic" numbers, like "640k". In any case, the Linux "use the ld.so name" approach will fail in the case of the loader always providing the local ld.so for any binary with the right magic number. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.