Date: Tue, 28 Nov 1995 18:00:37 +0100 (MET) From: grog@lemis.de (Greg Lehey) To: sos@FreeBSD.org Cc: hackers@FreeBSD.org (FreeBSD Hackers) Subject: Re: Enough already! (Was: Where is the documentation for ibcs2?) Message-ID: <199511281700.SAA26555@allegro.lemis.de> In-Reply-To: <199511281424.PAA00302@ra.dkuug.dk> from "sos@FreeBSD.org" at Nov 28, 95 03:24:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
sos@FreeBSD.org writes: > > In reply to Greg Lehey who wrote: > > > > Beyond that, I think we need to accept the fact that nobody has really > > explained how it works. As Terry suspects, my vi that crapped out the > > other day was trying to find a shared library. It's not clear from > > his mail whether it would have worked if it had found one. In any > > case, debugging it with gdb doesn't work: it doesn't get as far as > > being executed. > > You need a COFF debugger, preferably compile FreeBSD native... You don't understand. Watch my fingers: "it doesn't get as far as being executed." I have a gdb compiled under SCO 3.2.2 (by chance), though it still doesn't like the "user area" of the emulator: ptrace() bombs out looking for the eip value. To be more specific, you can't debug the vi problem because it bombs out of execve (look at the end of the function source: if things go wrong, it sends a SIGABRT). This is reasonable, since COFF effectively specifies multiple text segments in the header, and the file for one of them was missing. Possibly, though, we should consider a message stating the name of the missing file if it wasn't the executable itself. > > On the other hand, If anybody's interested, I have an almost complete > > set of GNU SVR3 binaries, including GNU libc, which I developed on an > > SCO system and which work there. I've tried out a statically linked > > bash, and it works, sort of. It does some strange things from time to > > time, such as deciding to receive an exit command, but it doesn't do > > that if I ktrace it. > > Hmm, at the time I & Sean "invented" the iBCS2 (kernel)support I had > a complete SCO system (3.2.2) running chrooted on my machine, including > all the gnu stuff, so it can be done. I have NO idea if it works on > the current iBCS2 system as it has only the COFF loader (and shlib > support) in common with our original implementaion, the rest is > stole^H^H^H^H^Htaken from NetBSD and differs from what I have on > my boxes... Well, I have had things run, anyway. I suppose I should try and fire up the SCO version of XFree86 :-) > It is funny though that now of a sudden iBCS2 support is "discovered" > but nobody cared back in 1994 when it crept into the tree, so I (and > I think Sean too) lost momentum on this rather big project. It's funny how a flame war can draw people's attention to things :-) > As Terry said there is MUCH MUCH more to iBCS2 emulation than the > kernel support, and we doesn't even have a start on that yet... > In my opinion we will at most get a 80% emulation, and that allready > would cost ALOT of work on the whole source tree, plus "reinventing" > lots & lots of SCO/svr3 utils etc etc... I don't think the idea should be to reinvent SCO. It should be to execute SCO executables. As you say: > By the time such a major undertaking could be done, nobody would > give a dime for that anymore as the world has moved meanwhile. > When one comes to that conclusion it is fair to say that one has > a pretty good understanding of the whole complex that is involved > in making iBCS2 emulation a "real thing". So when are we going for SVR4.2 emulation? Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511281700.SAA26555>