Subject: Re: COMPAT_IBCS2, SCO OSR5 executables SEGV on NetBSD 2.0
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 03/02/2005 23:41:01
In article <200503030321.j233L8Uq025641@ector.cs.purdue.edu>,
J Chapman Flack <email@example.com> wrote:
>You were right on the money: I added PROT_EXECUTE to the stack vmcmd and the
>SCO COFF executable runs without a hitch. So I created a function
>exec_ibcs2_coff_setup_stack to put in the execsw in place of the regular
>exec_setup_stack, and took PROT_EXECUTE back out of the regular setup, so only
>ibcs2_coff gets it. That solves my problem; I don't know if anyone else wants
>to dig deeper into what the executable is trying to do and find a better
>solution. My patch (against 2.0 RELEASE sources) is attached.
>Never did find a way to get objdump to recognize a SCO COFF executable (that
>might have been pilot error). Did however find that the trap is T_PROTFLT with
>err 0 and occurs at cs:0x23 eip:0xd4. Would have tried disassembling that in
>ddb if ddb allowed 'print $gdtr' but it wasn't that easy so I gave up. The stack
>at that point is ss:1f esp:bfbff928, eax is 0x2000000, ebx is bfbffff0, ds es fs
>gs are all 1f, eflags 0x202 and other regs zero in the trapframe.
>I still have no answer for the failing ibcs2 elf32 probe, but the executable
>I really wanted to run is coff and it runs now so I'll look into the elf
>probe some other time.
Thanks, I just fixed the stack issue you found.