From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCCw2-0000CX-2a for qemu-devel@nongnu.org; Tue, 19 Apr 2011 11:33:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCCw1-0003sw-2r for qemu-devel@nongnu.org; Tue, 19 Apr 2011 11:33:50 -0400 Received: from b.mail.sonic.net ([64.142.19.5]:42009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCCw0-0003sr-S2 for qemu-devel@nongnu.org; Tue, 19 Apr 2011 11:33:49 -0400 Message-ID: <4DADAB3E.3060502@twiddle.net> Date: Tue, 19 Apr 2011 08:33:18 -0700 From: Richard Henderson MIME-Version: 1.0 References: <4DAD53B5.9040001@samsung.com> In-Reply-To: <4DAD53B5.9040001@samsung.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH/RFC] Port Wine preloader to QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike McCormack Cc: riku.voipio@iki.fi, qemu-devel@nongnu.org, Scratchbox-devel@lists.scratchbox.org On 04/19/2011 02:19 AM, Mike McCormack wrote: > This is the only way I know to get qemu 0.14.0 to work reliably > with Scratchbox 2 (libsb2.so) > > The problem stems from two things: > > * The shared object loader is permitted to load LD_PRELOAD objects > below the QEMU load address (0x60000000), and does this with libsb2.so > > * QEMU's do_brk() (linux-user/syscall.c #738) uses MAP_FIXED, which > means after allocating enough memory, libsb2.so is clobbered. > > I have tried: > > * using plain QEMU 0.14.0 - crashes build perl > > * QEMU 0.14.0, appending -R 512M to qemu's command line in > scratchbox2/lua_scripts/argvenvp.lua, but > still get crashes when building perl. > > * modifying do_brk to not use MAP_FIXED - causes an out of memory > failure rather than a crash Did you try --enable-user-pie? It may not really help, but I'm curious. Honestly I'm not keen on this patch. This level of obfuscation on the startup and memory map of the host binary is just a gross hack working around the lack of proper page tables in user mode. If you really really need to get this working with a 32-bit host binary (rather than doing the sensible thing and using a 64-bit PIE binary), then working to enable CONFIG_SOFTMMU in user mode instead would be the most useful thing you could do. Indeed, this would fix a number of problems we currently have emulating other guests that have a page size different from the host. r~