Subject: COMPAT_IBCS2, SCO OSR5 executables SEGV on NetBSD 2.0
To: None <firstname.lastname@example.org>
From: J Chapman Flack <email@example.com>
Date: 12/29/2004 16:51:16
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. ;)
$ ktruss -t A ./wc
8749 ktruss emul(netbsd)
Does this look like the ELF executable isn't being recognized as needing
$ file wc
wc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), stripped
$ ldd 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.