[Top][All Lists]
[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~