Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Nov 1995 09:37:44 +0100 (MET)
From:      sos@freebsd.org
To:        grog@lemis.de
Cc:        sos@freebsd.org, hackers@freebsd.org
Subject:   Re: Enough already! (Was: Where is the documentation for ibcs2?)
Message-ID:  <199511290837.JAA01196@ra.dkuug.dk>
In-Reply-To: <199511281700.SAA26555@allegro.lemis.de> from "Greg Lehey" at Nov 28, 95 06:00:37 pm

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Greg Lehey who wrote:
> 
> > 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.

Hmm, I'm not sure who it is that don't understand here...

> 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.

Look at how our execution classes works, and you will now why this is
so. If you miss a shared lib it should say so though (at least in
the old iBCS2 code).

> > 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:

I was not talking about reinventing SCO, but if we go after letting
"Joe Smoe" install & run his iBCS2/SCO apps, we better have all the
pieces to the puzzle before letting him loose, otherwise he'll just
conclude that our iBCS2 emulation doesn't work..

I'll repeat again :
The kernel part of the iBCS2 emulation is only say 10% of what is
needed to run iBCS2/SCO apps, we must have a compatibel shell, ed
sed, echo, awk, and and and, or its just going to break one
way or another. We must have our own legal shared libs (plus an
environment to make these in case things change). Then we also
must have a "custom" util to install the stuff, plus whatever
config files, setups, filestructure etc etc etc that the SCO
apps expects from the system.
You se there is allmost no end to the list of things that must
be in place for this to be only remotely functional to the
random user.

> 
> So when are we going for SVR4.2 emulation?

Ha!, I've had my system run NCR svr4 binaries for almost a year
now, but there are even more things to make SVR4 run that 
running iBCS2 (and besides my code for this doesn't work
with the iBCS2 stuff we now have from NetBSD, it is nicely 
integrated into the "original" iBCS2 emulator).

Enough said on this topic....

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Soren Schmidt             (sos@FreeBSD.org)             FreeBSD Core Team
               So much code to hack -- so little time.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511290837.JAA01196>