From owner-freebsd-current Mon Apr 22 18:37:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA11943 for current-outgoing; Mon, 22 Apr 1996 18:37:34 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA11935 Mon, 22 Apr 1996 18:37:29 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id SAA03252; Mon, 22 Apr 1996 18:35:47 -0700 (PDT) Message-Id: <199604230135.SAA03252@austin.polstra.com> To: terry@lambert.org Cc: mmead@Glock.COM, smpatel@freebsd.org, current@freebsd.org, ec0@s1.GANet.NET Subject: Re: possible 4th option? [Re: kern/1102] In-reply-to: <199604222329.QAA18124@phaeton.artisoft.com> Date: Mon, 22 Apr 1996 18:35:47 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry wrote: > > > 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). That won't work any more. Linux and GNU have changed their binary load location to agree with FreeBSD/SVR4. > > > The 2nd > > > option you mention is the one in which you would use currently unused > > > bytes in the ELF e_ident tag. They're not unused -- they're _reserved_. If you stick anything other than 0 in them, you're technically no longer producing a valid ELF file. The analogous objection applies also to other ELF header fields such as e_type, e_machine, and e_flags. This may seem like a minor nit, but it's not. Suppose somebody else, say Sun, also decides to identify their executables using the extra bytes of the e_ident tag. Suppose their choice of values collides with yours. Too bad, you're out of luck. The ELF specification defines a mechanism for adding extra identifying information to an executable file: the PT_NOTE program header, and associated SHT_NOTE section. That's how I think that different kinds of ELF executables should be recognized. The good thing about NOTE sections is that each chunk of information contains, among other things, a "vendor tag" which is a string. It's not that likely that Sun is going to collide with a vendor tag of, say, "FreeBSD, Inc." or "Free Software Foundation". I'm going to try to add this kind of identification to our FreeBSD ELF executables, and fix the kernel to recognize them. (Unfortunately, as usual, the binutils code maze is doing its best to make this difficult for me.) I'd like to coordinate this with the Linux people, if they're interested. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth