Date: Tue, 2 Apr 1996 13:52:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sef@kithrup.com (Sean Eric Fagan) Cc: freebsd-questions@freebsd.org, mac@nibsc.ac.uk Subject: Re: Runs on SCO but not FreeBSD 2.1R Message-ID: <199604022052.NAA17015@phaeton.artisoft.com> In-Reply-To: <199604021817.KAA18566@kithrup.com> from "Sean Eric Fagan" at Apr 2, 96 10:17:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >% file ./muicairs > >./muicairs: Microsoft a.out separate pure segmented fixed-stack word-swapped > >not-stripped 286 small model executable Large Text Large Data not stripped > > "muicairs" will not run for a long, long time yet --- it's a '286 program, > to begin with, which would require 16-bit segments to work properly, and I'm > not sure they do. (Although the twin folks would like this [as, I'm sure, > would terry ;)], so it may be working.) Yes. I believe everything should work, always. 8-). One alternative would be to use what I call a "PEM" -- Processor Environment Module. Specifically, for the PPC and DEC Alpha, I want to be able to run i386 binaries, like BSDI Netscape. To accomplish this, I write an ECM (Execution Class Module) which I load as an LKM which invokes an ECM specific PEM with the original arguments intact. The PEM uses argv[ 0] to identify the binary it's supposed to run. This requires that execution classes be handled by magic number, and call-dispatched from there: the fix I suggested for the LINUX_EMUL code before it was simply main-lined and the #ifdef's removed (a mistake, IMO). When an attempt is made to execute a file with a magic number handled by a PEM, the ECM invokes the PEM, much in the way that shell processors are invoked instead of the the program they are operating on. The PEM simulates a given processor environment. Specifically, it MMAP's the executable into its data address space, and runs a simulated processor for all user space code. When a kernel trap occurs, the PEM translates the calls based on the environment being provided into local system calls: system calls are executed as native code. Because the PEM must translate the address range on system calls for the 0 or 4k load address, and because the trap gates differ, it is desirable to make the PEM take "personality modules" for ABI compatability in a processor range. These define the system interface, including trap vectors used, etc., and translate the address by the mapping range so that the fixed references in the simulated environment match the correct virtual address in the PEM's address space where the code actually lives. This is less of a problem for ELF, which loads quite high, though SVR4 automatically patches page 0 references instead of failing them for binary compatability with programs that pass NULL pointers to strcpy(), etc. Linux ELF loads lower than standard ELF, actually: in standard ELF, there is a reserve area to allow the program loader to map the ld.so into the process address space instead of making the crt0.o do the dirty work: hence no difference between shared library crt0.o and non-shared library versions, and no problems using dlopen() from statically linked binaries. Being loaded high means that if the PEM is linked low, it can MMAP the ELF image at the expected address without needing to do traslation -- a.out (zmagic/qmagic/etc.) isn't that lucky. 8-(. Obviously, one of the major issues is stack growth. Another is that the personality modules (PEMPM's) are hard coded at present instead of being modules. Probably the single biggest issue is use of registers instead of stack for system calls: thank God only Linux has this screwup. Note that it would be a small step to using the PEMPM's as the basis for ABI emulation in native processor environments as well (using kernel file I/O to load them as part of the LKM init for the native processor ECM's). Clearly, this could work on an i386/i486/i586 system as well, letting an i386 system execute SPARC or 68k or ...i286 code. I happened to have a head-start on the i386 because of PCEMU. You'd need to find a 286 simulator somewhere that you could hack; the kernel changes are pretty easy (though the recent LINUX_EMUL change does complicate things somewhat). Finding one might be quite a chore... > It's also an x.out program, which currently does not load (I wrote an x.out > loader, once, but x.out programs wouldn't work; I don't know why). I wrote one back in the 0.1+patchkit days -- seemed to work fine for me as long as I didn't need the 286emul code. Xenix 2.3.1(?) binaries ran fine. Novell thinks (incorrectly) that it owns that code. 8-(. > Does your kernel config file have the 'options IBCS2_COMPAT'? It needs that > as well, I believe. Erk. Another option that should be replaced by function registration via callback in the LKM init routine. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604022052.NAA17015>