Date: Thu, 28 Mar 1996 19:33:22 -0500 (EST) From: Sujal Patel <smpatel@wam.umd.edu> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: kern/1102: Differentiation of FreeBSD & Linux ELF binaries [patch] Message-ID: <Pine.NEB.3.92.960328193045.194C-100000@xi.dorm.umd.edu> In-Reply-To: <199603280945.KAA24169@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Mar 1996, J Wunsch wrote: > > Maybe I was a bit too tired when I wrote this patch, but I don't really > > think it's a good idea to let the kernel parse the environment :) > > Well, doesn't the execve() code have to copy the environment over to > the new address space anyway? This is true that the kernel brings it into kernel space, so parsing it is trivial. I was just pointing out that I don't think it's the kernel place to be doing this (should be done in libc). > I remember that Data General did some hacking in their ELF binaries to > differentiate between the ``ABI'' and ``DG/UX'' ELF binaries (where > they could use several optimizations if not using the m88k ABI). So i > figure there is some `flags' field inside ELF that can be (ab)used. > The question is: do Linux and SVR4 ELF binaries differentiate in any > way? (We could certainly differentiate our own binaries, but we'll > also have to determine 3rd party programs.) Without abusing some field (like the unused part of e_ident), I don't think there is any way to differentiate static binaries... There are some gross hacks to find out what OS compiled it, but none are really acceptable (even the way we determine what OS made dynamic binaries is kinda nasty, but there really is no other choice). Sujal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.92.960328193045.194C-100000>