From: Mike McCormack <mj.mccormack@samsung.com>
To: Richard Henderson <rth@twiddle.net>
Cc: riku.voipio@iki.fi, qemu-devel@nongnu.org,
Scratchbox-devel@lists.scratchbox.org
Subject: Re: [Qemu-devel] [PATCH/RFC] Port Wine preloader to QEMU
Date: Wed, 20 Apr 2011 10:04:11 +0900 [thread overview]
Message-ID: <4DAE310B.6070104@samsung.com> (raw)
In-Reply-To: <4DADAB3E.3060502@twiddle.net>
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
next prev parent reply other threads:[~2011-04-20 1:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 9:19 [Qemu-devel] [PATCH/RFC] Port Wine preloader to QEMU Mike McCormack
2011-04-19 15:33 ` Richard Henderson
2011-04-20 1:04 ` Mike McCormack [this message]
2011-04-19 15:48 ` Riku Voipio
2011-04-19 16:19 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DAE310B.6070104@samsung.com \
--to=mj.mccormack@samsung.com \
--cc=Scratchbox-devel@lists.scratchbox.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.