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~
