Linux emulation on FreeBSD AMD64
yuri.pankov at gmail.com
Sun Oct 28 01:08:18 PDT 2007
On Sun, 2007-10-28 at 00:08 +0300, Valery V.Chikalov wrote:
> Ivan Voras wrote:
> > Valery V.Chikalov wrote:
> >> Hi, list.
> >> Now being inspired the great performance improvements on multiprocessors
> >> configurations I am trying to switch to FreeBSD 7.0 version, moreover on
> >> AMD64 architecture. Must I expect some regression in support old Linux
> >> application here? Are some theoretical obstacles exists that linux
> >> application which successfully worked on FreeBSD from 5.0 up to 6.2
> >> can not be running on 7.0 AMD64?
> > AFAIK Linux emulation on AMD64 works only for 32-bit code, so you have
> > practically two emulation layers: linux-freebsd and 32-64. There's all
> > kinds of things that might go wrong.
> > This is a "generic" answer, I don't really know the exact answer to your
> > question.
> Hi, Ivan.
> Thank you for your answer.
> Yes I know that Linux emulation is 32 bit ever on AMD64 FreeBSD and that
> exactly what I need as I own old 32bit 9.0.1 Oracle server.
> I have investigated this problem little more.
> Oracle(+ rh7) can be successfully started on FreeBSD 7.0 (i386)
> SMP capable kernel, SHED_ULE, Core2Duo and so on...
> I fond this: http://wiki.freebsd.org/linux-kernel/ltp
> I don't know how actual this info now, it seems little bit old.
> I did:
> grep UNIMPL /sys/amd64/linux32/syscalls.master > amd64.unimpl.txt
> grep UNIMPL /sys/i386/linux/syscalls.master > i386.unimpl.txt
> diff i386.unimpl.txt amd64.unimpl.txt
> < 28 AUE_FSTAT UNIMPL fstat
> < 86 AUE_USELIB UNIMPL linux_uselib
> < 101 AUE_NULL UNIMPL ioperm
> < 113 AUE_NULL UNIMPL vm86old
> < 123 AUE_NULL UNIMPL modify_ldt
> < 166 AUE_NULL UNIMPL vm86
> < 244 AUE_NULL UNIMPL linux_get_thread_area
> So there is some regression between i386 and AMD64 in a number of system
> calls emulated.
> But Oracle not dumping core with signal 12(non-existent system call)
> It's saying:
> 27122, 00000, "unable to protect memory"
> // *Cause: mprotect() call failed
> and than dumps core with signal 11.
> I instrumented mprotect(2) system call in linux32_machdep.c with
> -return (mprotect(td, &bsd_args));
> +ret = mprotect(td, &bsd_args);
> +printf("mprotect addr:%lx, return %d\n", uap->addr, ret);
> +return ret;
> and got something like:
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a27d000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7c1000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7cd000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7e2000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7ef000, return 0
> Oct 27 19:43:09 tiger kernel: mprotect addr:55c00000, return 13
> Oct 27 19:43:09 tiger kernel: mprotect addr:55c81000, return 13
> where 13 is EACCES.
> So, I think we have some regression in supporting old linux binaries on
> AMD64 and possibly not connected with missing system calls.
> Don't know where to move from here.
> BTW, ktrace don't usable for me on FreeBSD 7.0 any arch,
> kdump dumping core on freebsd6_mmap system call.
Are you using linux_kdump (devel/linux_kdump or, much faster, with
More information about the freebsd-emulation