From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCLp6-0007K8-62 for qemu-devel@nongnu.org; Tue, 19 Apr 2011 21:03:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCLp4-0001Kh-Qs for qemu-devel@nongnu.org; Tue, 19 Apr 2011 21:03:15 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:49038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCLp4-0001KT-EY for qemu-devel@nongnu.org; Tue, 19 Apr 2011 21:03:14 -0400 Received: from epmmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTP id <0LJX000WLEX9FW90@mailout3.samsung.com> for qemu-devel@nongnu.org; Wed, 20 Apr 2011 10:03:09 +0900 (KST) Received: from TNRNDGASPAPP1.tn.corp.samsungelectronics.net ([165.213.149.150]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0LJX00J6YEXALT@mmp2.samsung.com> for qemu-devel@nongnu.org; Wed, 20 Apr 2011 10:03:10 +0900 (KST) Date: Wed, 20 Apr 2011 10:04:11 +0900 From: Mike McCormack In-reply-to: <4DADAB3E.3060502@twiddle.net> Message-id: <4DAE310B.6070104@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <4DAD53B5.9040001@samsung.com> <4DADAB3E.3060502@twiddle.net> Subject: Re: [Qemu-devel] [PATCH/RFC] Port Wine preloader to QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: riku.voipio@iki.fi, qemu-devel@nongnu.org, Scratchbox-devel@lists.scratchbox.org On 04/20/2011 12:33 AM, Richard Henderson wrote: > Did you try --enable-user-pie? It may not really help, but I'm curious. No. I don't think it will help because placement of the executable probably doesn't account for how large its heap will grow. You'll still run out of memory as the heap grows and runs into an LD_PRELOAD'ed shared object that's been mapped below 0x60000000, then crash without your do_brk() MAP_FIXED patch, or fail with some error code with it. > 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. This mechanism has been used in Wine for 6 years, but Wine doesn't have any other way to guarantee the memory layout. > 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. Yes, having page tables in user mode emulation would help, but would probably make the target executable considerably slower too. thanks, Mike