Mikhail Teterin wrote:> Hello!
>
> I have a 7.0 system (amd64) and am trying to run a FreeBSD-4 executable.
> It dies on startup with "bad system call". The core shows, that
it is
> simply trying to mmap something.
>
> I have the following COMPAT-options enabled in my kernel:
>
> options COMPAT_43 # Needed by COMPAT_LINUX32
> options COMPAT_IA32 # Compatible with i386 binaries
> options COMPAT_FREEBSD4 # Compatible with FreeBSD4
> options COMPAT_LINUX32 # Compatible with i386 linux
binaries
>
> Should not that be enough? Thanks!
Only a guess: add COMPAT_FREEBSD6 and try again?
date: 2007/07/04 22:47:37; author: peter; state: Exp; lines: +20 -9
Create new syscalls for mmap(), lseek(), pread(), pwrite(), truncate()
and ftruncate(), but without the pad arg.
There are several reasons for this. Consider 'mmap()'. On AMD64, the
function call (and syscall) ABI allow for 6 register arguments.
Additional arguments go on the stack. mmap(2) has 6 arguments.
However, the syscall definition has an extra 'int pad' argument. This
pushes it to 7 arguments, which means one must spill into the memory
stack. Since the kernel API doesn't match userland API, we have a hack
in libc - libc/sys/mmap.c. This implements the userland API by calling
__syscall() with an extra argument and the pad argument, for a total of
8 args. This is all unnecessary and inconvenient for several things,
including the kernel's syscall handler code which now has to handle
merging stack arguments with register arguments. It is a big deal for
certain 3rd party code.
I'm adding libc glue to make the transition totally painless. I had
intended to mark the old syscalls as COMPAT6, but the potential to shoot
your feet by building a new kernel without COMPAT_FREEBSD6 but with a
slighly older userland was too great. For now, they have manual
"freebsd6_" prefixes rather than being COMPAT6. They will go back to
being marked 'COMPAT6' after 7-stable starts.
Cheers,
--
Xin LI <delphij@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve!