Quoting Mark Willey,

>    380 ktrace   RET   ktrace 0
>    380 ktrace   CALL  execve(0xf7bfda77,0xf7bfd9b8,0xf7bfd9c0)
>    380 ktrace   NAMI  "./tsetup"
>    380 tsetup   EMUL  "svr4"
>    380 tsetup   RET   execve 0
>    380 tsetup   CALL  setegid(0xf7bfd990)
>    380 tsetup   RET   setegid 0
>    380 tsetup   CALL  #45 (unimplemented plock)
>    380 tsetup   PSIG  SIGSYS SIG_DFL
>    380 tsetup   NAMI  "tsetup.core"

Ah.. Your problem is that the binary is a statically linked Linux ELF
binary, which can not be distinguished from a statically linked ELF
binary for the same processor created for another OS. This is a general ELF
problem.

What happens here is that the SVR4 emul code sees it as a valid SVR4 binary,
and tries to run it. With bad results, obviously.

There is no good solution for this (yet), so what you can do if something like
this happens is to disable the emulation that gets in the way. So take
out COMPAT_SVR4 out of your config file and try again.. Or: reverse the
order of the elf_probe funcs array in /sys/kern/exec_elf.c (line 58), so
that Linux emulation is tried first.

It may be a safe assumption that there are more statically linked
Linux ELF binaries around than SVR4, so perhaps I should just make that
change in the tree too.

- Frank