From: Richard Henderson <rth@twiddle.net>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] exec: Don't request an address for code_gen_buffer if -fpie
Date: Sun, 07 Oct 2012 12:20:25 -0700 [thread overview]
Message-ID: <5071D5F9.4010106@twiddle.net> (raw)
In-Reply-To: <CAAu8pHvgNQHWq=gEiGvbXky-zHk7vy3fBSXUggoue1_opqyc1w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On 10/07/2012 09:34 AM, Blue Swirl wrote:
>> > +#ifdef USE_MMAP
>> > + code_gen_buffer = mmap((void *)start, code_gen_buffer_size,
>> > + PROT_WRITE | PROT_READ | PROT_EXEC,
>> > + flags, -1, 0);
>> > + if (code_gen_buffer == MAP_FAILED) {
>> > + fprintf(stderr, "Could not allocate dynamic translator buffer\n");
>> > + exit(1);
>> > }
>> > #else
>> > code_gen_buffer = g_malloc(code_gen_buffer_size);
>> > map_exec(code_gen_buffer, code_gen_buffer_size);
> In this branch (e.g. mingw32), 'start' is unused:
> /src/qemu/exec.c: In function 'code_gen_alloc':
> /src/qemu/exec.c:531: warning: unused variable 'start'
Well, I've rearranged the code to handle this, and it does avoid the warning.
But I'm not sure I like the two separate blocks. Especially for the x86_64
MAP32 case. Perhaps we're better off with an __attribute__((unused)) there?
r~
[-- Attachment #2: z --]
[-- Type: text/plain, Size: 2993 bytes --]
diff --git a/exec.c b/exec.c
index 8f3bc74..704426c 100644
--- a/exec.c
+++ b/exec.c
@@ -527,15 +527,14 @@ static void code_gen_alloc(unsigned long tb_size)
#else
#ifdef USE_MMAP
int flags = MAP_PRIVATE | MAP_ANONYMOUS;
+ uintptr_t start = 0;
#endif
- uintptr_t max_buf = -1, start = 0;
+ size_t max_buf = ~(size_t)0;
- /* Constrain the size and position of the buffer based on the host cpu. */
+ /* Constrain the size of the buffer based on the host cpu. */
#if defined(__x86_64__)
-# if !defined(__PIE__) && !defined(__PIC__) && defined(MAP_32BIT)
- /* Force the memory down into low memory with the executable.
- Leave the choice of exact location with the kernel. */
- flags |= MAP_32BIT;
+# if !defined(__PIE__) && !defined(__PIC__) \
+ && defined(USE_MMAP) && defined(MAP_32BIT)
/* Cannot expect to map more than 800MB in low memory. */
max_buf = 800 * 1024 * 1024;
# else
@@ -545,22 +544,12 @@ static void code_gen_alloc(unsigned long tb_size)
#elif defined(__sparc__) && HOST_LONG_BITS == 64
/* Maximum range of direct branches between TB (via "call"). */
max_buf = 2ul * 1024 * 1024 * 1024;
- start = 0x40000000ul;
#elif defined(__arm__)
/* Keep the buffer no bigger than 16MB to branch between blocks */
max_buf = 16 * 1024 * 1024;
#elif defined(__s390x__)
- /* Map the buffer so that we can use direct calls and branches. */
/* We have a +- 4GB range on the branches; leave some slop. */
max_buf = 3ul * 1024 * 1024 * 1024;
- start = 0x90000000ul;
-#endif
-#if defined(__PIE__) || defined(__PIC__)
- /* Don't bother setting a preferred location if we're building
- a position-independent executable. We're more likely to get
- an address near the main executable if we let the kernel
- choose the address. */
- start = 0;
#endif
/* Size the buffer. */
@@ -581,6 +570,23 @@ static void code_gen_alloc(unsigned long tb_size)
}
#ifdef USE_MMAP
+ /* Constrain the position of the buffer based on the host cpu.
+ Note that these addresses are chosen in concert with the
+ addresses assigned in the relevant linker script file. */
+# if defined(__PIE__) || defined(__PIC__)
+ /* Don't bother setting a preferred location if we're building
+ a position-independent executable. We're more likely to get
+ an address near the main executable if we let the kernel
+ choose the address. */
+# elif defined(__x86_64__) && defined(MAP_32BIT)
+ /* Force the memory down into low memory with the executable.
+ Leave the choice of exact location with the kernel. */
+ flags |= MAP_32BIT;
+# elif defined(__sparc__) && HOST_LONG_BITS == 64
+ start = 0x40000000ul;
+# elif defined(__s390x__)
+ start = 0x90000000ul;
+# endif
code_gen_buffer = mmap((void *)start, code_gen_buffer_size,
PROT_WRITE | PROT_READ | PROT_EXEC,
flags, -1, 0);
next prev parent reply other threads:[~2012-10-07 19:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-04 21:31 [Qemu-devel] [PATCH] exec: Don't request an address for code_gen_buffer if -fpie Richard Henderson
2012-10-07 16:34 ` Blue Swirl
2012-10-07 19:20 ` Richard Henderson [this message]
2012-10-07 19:40 ` Blue Swirl
2012-10-12 21:20 ` [Qemu-devel] [PATCH v3 0/4] Better allocation of code_gen_buffer with -fpie Richard Henderson
2012-10-12 21:20 ` [Qemu-devel] [PATCH 1/4] exec: Split up and tidy code_gen_buffer Richard Henderson
2012-10-13 13:33 ` Blue Swirl
2012-10-15 20:16 ` Richard Henderson
2012-10-12 21:20 ` [Qemu-devel] [PATCH 2/4] exec: Don't make DEFAULT_CODE_GEN_BUFFER_SIZE too large Richard Henderson
2012-10-12 21:20 ` [Qemu-devel] [PATCH 3/4] exec: Do not use absolute address hints for code_gen_buffer with -fpie Richard Henderson
2012-10-12 21:20 ` [Qemu-devel] [PATCH 4/4] exec: Allocate code_gen_prologue from code_gen_buffer Richard Henderson
2012-10-12 21:41 ` [Qemu-devel] [PATCH 5/4] exec: Make MIN_CODE_GEN_BUFFER_SIZE private to exec.c Richard Henderson
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=5071D5F9.4010106@twiddle.net \
--to=rth@twiddle.net \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).