Christos Zoulas said:

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

>>With an ELF executable, the results are different: I get SIGABRT instead
>>of SIGSEGV.  ;)

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

One of the problems with OSR5, as I remember it, is that the ELF format used
at that time by SCO was not SVR4 ELF binary compatible.

SCO OSR5 would run all old SVR3 binaries.

I see this caveat in the compat_ibcs2 manpage:

     iBCS2 supports COFF, ELF, and x.out (XENIX) binary formats.  Binaries
     from SCO OpenServer (version 5.x) are the only ELF binaries that have
     been tested.  Most programs should work, but not ones that use or depend
     on:

           kernel internal data structures
           STREAMS drivers (other than TCP/IP sockets)
           local X displays (uses a STREAMS pipe)
           virtual 8086 mode

And under BUGS:

     16/32/64 bit offsets may not be handled correctly in all cases.

-- 
Rick Kelly  rmk@rmkhome.com  www.rmkhome.com