Date: Tue, 23 Apr 96 9:23:07 MDT From: Greg Lehey <lehey.pad@sni.de> To: jdp@polstra.com (John Polstra) Cc: terry@lambert.org, mmead@Glock.COM, smpatel@freebsd.org, current@freebsd.org, ec0@s1.GANet.NET Subject: Re: possible 4th option? [Re: kern/1102] Message-ID: <199604230723.JAA09548@nixpbe.pdb.sni.de> In-Reply-To: <199604230135.SAA03252@austin.polstra.com>; from "John Polstra" at Apr 22, 96 6:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> 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. > > 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". Sounds reasonable, even if it's a bit tedious. > 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. Good idea. While you're at it, why not give Sun and SCO a chance to cooperate? Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604230723.JAA09548>