qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH/RFC] Port Wine preloader to QEMU


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH/RFC] Port Wine preloader to QEMU
Date: Tue, 19 Apr 2011 08:33:18 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9

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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]