From owner-freebsd-emulation@FreeBSD.ORG Sun Nov 4 12:20:43 2007 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CD4F16A419 for ; Sun, 4 Nov 2007 12:20:43 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id C7F8413C4B6 for ; Sun, 4 Nov 2007 12:20:40 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8EF76669AD0; Sun, 4 Nov 2007 13:20:25 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtMhxyGJ1NHg; Sun, 4 Nov 2007 13:20:23 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id BFDE3669A70; Sun, 4 Nov 2007 13:20:23 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id lA4CKNEp005601; Sun, 4 Nov 2007 13:20:23 +0100 (CET) (envelope-from rdivacky) Date: Sun, 4 Nov 2007 13:20:23 +0100 From: Roman Divacky To: "Valery V.Chikalov" Message-ID: <20071104122023.GA5528@freebsd.org> References: <4721AB07.20708@novakom.com.ua> <4723A8D6.6020002@chikalov.dp.ua> <20071031180639.GA93259@cons.org> <47298F10.4050301@chikalov.dp.ua> <20071101152550.GA10868@cons.org> <472B0454.9040408@chikalov.dp.ua> <472B9CD1.1010607@chikalov.dp.ua> <472DAF60.9040008@chikalov.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472DAF60.9040008@chikalov.dp.ua> User-Agent: Mutt/1.4.2.3i Cc: Martin Cracauer , freebsd-emulation@freebsd.org Subject: Re: Linux emulation on FreeBSD AMD64 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2007 12:20:43 -0000 > So, now all from mprotect calls executing with success, > but 3 memory areas still missing execute bit and oracle as effect coredumps. > In linux_mmap_common there is the same trick with "prot" argument like > in linux_mprotect: > > /* > * PROT_READ, PROT_WRITE, or PROT_EXEC implies PROT_READ and PROT_EXEC > * on Linux/i386. We do this to ensure maximum compatibility. > * Linux/ia64 does the same in i386 emulation mode. > */ > bsd_args.prot = linux_args->prot; > if (bsd_args.prot & (PROT_READ | PROT_WRITE | PROT_EXEC)) > bsd_args.prot |= PROT_READ | PROT_EXEC; > > > but turning on the debug for the linux_mmap_common gives no result. > So linux_mmap_common not taking part in creating and changing rights of > others 3 memory areas. So the question is what is the origin of this > memory chunks? By calling which function there was created or managed? > Maybe in this function there is place for the same hack with > linux_args->prot to bsd_args.prot mapping? I am a little confused.. you are saying that 1) oracle calls m* on 0x50000000 with PROT_EXEC but fbsd does not set it on the map or 2) oracle does not set this protection at all and the OS is supposed to have set on default? roman