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?

$ file wc
wc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), stripped

$ ldd wc
wc:
         /usr/lib/libc.so.1 => not found

$ ls -l /emul/ibcs2/usr/lib/libc.so.1
-r-xr-xr-x  1 operator  kmem  359652 Apr 23  1995 /emul/ibcs2/usr/lib/libc.so.1

I found this comment in /usr/src/sys/compat/ibcs2/ibcs2_exec_elf32.c:

 * The SCO compiler adds the string "SCO" to the .notes section of all
 * binaries I've seen so far.

It seems to be there:

$ readelf -x 14 wc       

Hex dump of section '.note':
  0x00000000 004f4353 00000001 0000000c 00000004 ............SCO.
  0x00000010          00010000 00000003 00010001 ............

Maybe there's a bug in the ibcs2 elf recognition?  Hmm - is there any way
to exec a file and force a specified emulation to be used, just to see if
it works right that way?

The COFF problem looks less simple.  I was hoping the ktruss would show
something interesting, like an obviously bogus system call before the SEGV,
but no, it's just right after the exec.  gdb is not immediately useful:

This GDB was configured as "i386--netbsdelf"
..."/tmp/idcomp": not in executable format: File format not recognized

Core was generated by `idcomp'.
Program terminated with signal 11, Segmentation fault.

warning: Couldn't find general-purpose registers in core file.

#0  0x00000000 in ?? ()

If I wanted to debug this further, would I start by building an ibcs2/coff
version of gdb just to learn what I can from the core file?  Moving the core
file back to the SCO box doesn't help; that debugger doesn't grok this
core file format.

Any suggestions?

Thanks,
-Chap