From owner-freebsd-current Mon Apr 22 16:35:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA27924 for current-outgoing; Mon, 22 Apr 1996 16:35:18 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA27912 Mon, 22 Apr 1996 16:35:15 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA18124; Mon, 22 Apr 1996 16:29:55 -0700 From: Terry Lambert Message-Id: <199604222329.QAA18124@phaeton.artisoft.com> Subject: Re: possible 4th option? [Re: kern/1102] To: ec0@s1.GANet.NET (Eric Chet) Date: Mon, 22 Apr 1996 16:29:55 -0700 (MST) Cc: mmead@Glock.COM, smpatel@FreeBSD.org, current@FreeBSD.org In-Reply-To: from "Eric Chet" at Apr 22, 96 08:33:29 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-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I was looking through your discussion on the difficulties of > > differentiating a Linux ELF binary from a FreeBSD ELF binary. The 2nd > > option you mention is the one in which you would use currently unused > > bytes in the ELF e_ident tag. What you proposed for this method of > > distinguishing the two different systems' binaries was to modify each > > Linux executable so that it has an identification byte in it. Since at > > this point we only (am I wrong here?) support Linux and FreeBSD ELF > > binaries, wouldn't it be sufficient to have our ELF binary generation > > utilities put an identifier for FreeBSD into the ELF binary as mentioned > > above, and if that is detected, use the FreeBSD sysvec set, otherwise > > assume the Linux sysvec set? This is unnecessary (hint: look at the Linux ELF binary load location, vs. the FreeBSD/SVR4 load location). > Hello > Well how about Slowaris ELF binaries? This is one of the fundamental flaws in using the EABI/ABI spec to constrain the ELF format (as SEF has pointed out). There is some possiblity of recognizing known crt0.o code; this is easily generalized, since there is no specific compatability requirements for keeping the existing FreeBSD ELF crt0.o (since ELF has not yet been deployed -- now you are glad we waited. 8-)). I suspect we will want the loader to load ld.so at 0x80001000 (or higher) to allow segment identifier based paging to take place. This type of paging would be necessary if we wanted to, for instance, migrate to the University of Utah OMOS implementation in place of the ELF/BSD shared library implementation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.