In article <200412292151.iBTLpGUq011152@ector.cs.purdue.edu>,
J Chapman Flack <flack@cs.purdue.edu> wrote:
>I have an old SCO OSR5 box that I'd like to retire, but I'd like to keep
>the most costly applications I had for it, and move them to a NetBSD box.
>
>My kernel is compiled with COMPAT_IBCS2 and I have an /emul/ibcs2 with
>shlib, lib, and usr/lib populated with the SCO shared libs.
>
>The only thing I can get a COFF executable to do is dump core:
>
>$ ktruss -t A ./mapleV
>  4341 ktruss   emul(netbsd)
>  4341 mapleV   emul(ibcs2)
>  4341 mapleV   execve("./mapleV", 0xbfbff810, 0xbfbff818) JUSTRETURN
>  4341 mapleV   SIGSEGV SIG_DFL
>
>To check if it wasn't just Maple, I also tried one of the few COFF
>executables that came with OSR5, /lib/idcomp, and it did the same thing:
>
>$ ktruss -t A ./idcomp
> 12066 ktruss   emul(netbsd)
> 12066 idcomp   emul(ibcs2)
> 12066 idcomp   execve("./idcomp", 0xbfbff820, 0xbfbff828) JUSTRETURN
> 12066 idcomp   SIGSEGV SIG_DFL
>
>With an ELF executable, the results are different: I get SIGABRT instead
>of SIGSEGV.  ;)
>
>$ ./wc
>Abort 
>
>$ ktruss -t A ./wc
>  8749 ktruss   emul(netbsd)
>
>Does this look like the ELF executable isn't being recognized as needing
>emulation?

What does it say next?

I think that the problem could be with the non-executable stack and data
mappings that are new in 2.0. I would add DEBUG_EXEC to my kernel and
see what that prints. Also you can put some debugging in the trap handler
for segv in arch/i386/i386/trap.c and print the PC where it dies. Then
with objdump --dissassemble you can see what it is trying to do.

christos