In article <200503030321.j233L8Uq025641@ector.cs.purdue.edu>,
J Chapman Flack  <flack@cs.purdue.edu> 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.

christos