All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Weil <sw@weilnetz.de>
To: Richard Henderson <rth@twiddle.net>
Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/5] exec: Do not use absolute address hints for code_gen_buffer with -fpie
Date: Sun, 18 Nov 2012 21:48:11 +0100	[thread overview]
Message-ID: <50A9498B.2040209@weilnetz.de> (raw)
In-Reply-To: <1350372614-30041-4-git-send-email-rth@twiddle.net>

Am 16.10.2012 09:30, schrieb Richard Henderson:
> The hard-coded addresses inside alloc_code_gen_buffer only make sense
> if we're building an executable that will actually run at the address
> we've put into the linker scripts.
>
> When we're building with -fpie, the executable will run at some
> random location chosen by the kernel.  We get better placement for
> the code_gen_buffer if we allow the kernel to place the memory,
> as it will tend to to place it near the executable, based on the
> PROT_EXEC bit.
>
> Since code_gen_prologue is always inside the executable, this effect
> is easily seen at the end of most TB, with the exit_tb opcode, and
> with any calls to helper functions.
>
> Signed-off-by: Richard Henderson<rth@twiddle.net>
> ---
>   exec.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/exec.c b/exec.c
> index 6c0b2d7..5e33a3d 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -578,7 +578,12 @@ static inline void *alloc_code_gen_buffer(void)
>       /* 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(__x86_64__)&&  defined(MAP_32BIT)
> +# 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;


This patch breaks the TCG interpreter. Here is a test run on Debian 
x86_64 (output shortened):

$ ./configure --enable-debug --enable-tcg-interpreter 
--target-list=i386-softmmu --disable-docs
$ make
$ gdb --args i386-softmmu/qemu-system-i386 -L pc-bios
(gdb) r
Starting program: i386-softmmu/qemu-system-i386 -L pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe8f73700 (LWP 1446)]
[New Thread 0x7fffe0470700 (LWP 1447)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8f73700 (LWP 1446)]
0x00005555558e7ded in tcg_qemu_tb_exec (cpustate=0x55555656f7e0, 
tb_ptr=0xeab74acb <Address 0xeab74acb out of bounds>) at tci.c:445
445             TCGOpcode opc = tb_ptr[0];
(gdb) q

QEMU crashes early while executing a jmp opcode.

This patch restores functionality:

diff --git a/exec.c b/exec.c
index 8435de0..44e4504 100644
--- a/exec.c
+++ b/exec.c
@@ -564,7 +564,7 @@ static inline void *alloc_code_gen_buffer(void)
      /* 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__)
+# if !defined(CONFIG_TCG_INTERPRETER) && (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

Regards

Stefan W.

  reply	other threads:[~2012-11-18 20:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16  7:30 [Qemu-devel] [PATCH v4 0/5] Better allocation of code_gen_buffer Richard Henderson
2012-10-16  7:30 ` [Qemu-devel] [PATCH 1/5] exec: Split up and tidy code_gen_buffer Richard Henderson
2012-10-16  7:30 ` [Qemu-devel] [PATCH 2/5] exec: Don't make DEFAULT_CODE_GEN_BUFFER_SIZE too large Richard Henderson
2012-10-16  7:30 ` [Qemu-devel] [PATCH 3/5] exec: Do not use absolute address hints for code_gen_buffer with -fpie Richard Henderson
2012-11-18 20:48   ` Stefan Weil [this message]
2012-11-19 16:27     ` Richard Henderson
2012-10-16  7:30 ` [Qemu-devel] [PATCH 4/5] exec: Allocate code_gen_prologue from code_gen_buffer Richard Henderson
2012-10-16  7:30 ` [Qemu-devel] [PATCH 5/5] exec: Make MIN_CODE_GEN_BUFFER_SIZE private to exec.c Richard Henderson
2012-10-20  8:47 ` [Qemu-devel] [PATCH v4 0/5] Better allocation of code_gen_buffer Blue Swirl

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=50A9498B.2040209@weilnetz.de \
    --to=sw@weilnetz.de \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --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.