From: Richard Henderson <rth@twiddle.net>
To: Ed Maste <emaste@freebsd.org>
Cc: Michael Tokarev <mjt@tls.msk.ru>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Could configure generate QEMU's linker scripts?
Date: Tue, 21 May 2013 11:14:43 -0700 [thread overview]
Message-ID: <519BB993.7070703@twiddle.net> (raw)
In-Reply-To: <CAPyFy2BETwnU-_cxEXTJSBk-yvqnE7SZGXJp5r+MCyiPv4+V_A@mail.gmail.com>
On 05/21/2013 10:51 AM, Ed Maste wrote:
> On 20 May 2013 13:21, Richard Henderson <rth@twiddle.net> wrote:
>> In general I believe that using the -Ttext-segment ADDR flag for ld
>> would completely obviate the need for even editing the link script.
>
> That sounds cleaner, although there's a wrinkle for FreeBSD. We're
> still using binutils version 2.17.50 in the base system, since it is
> the last one licensed under GPLv2, and it doesn't support the
> -Ttext-segment flag. There is -Ttext but it still leaves some parts
> behind at the default load address. I assume that the reason for
> changing the QEMU load address is to leave the default free for the
> guest application to use, making -Ttext unsuitable.
>
> If we can't use an approach along the lines of my earlier sed script
> we'll just have to find a way to support -Ttext-segment in FreeBSD,
> either by having the original patch that introduced it made available
> under GPLv2, reimplementing the functionality, or by requiring use of
> a later binutils (from the FreeBSD ports tree).
Certainly using a decent binutils would be easiest.
Although for the purposes of getting the qemu application out of the virtual
address space that the *-bsd-user guest will want to use, it might be better to
use -fPIE. At least on linux that tends to put the x86_64 host binary up in
(very) high memory.
The best long term solution is to be able to enable softmmu for *-user guests.
It's the only way to make certain 64-on-32 combinations work, and the only way
to fix a myriad of problems that occur when the host and guest page sizes don't
match. At which point it doesn't matter where the host binary resides.
> One oddity I noticed is that alpha and s390x seem to not use the ld
> script (with the comment "The default placement of the application is
> fine" in configure), so I'm not sure why QEMU includes those files.
I thought I deleted those when I changed the configure script...
r~
next prev parent reply other threads:[~2013-05-21 18:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-19 16:30 [Qemu-devel] Could configure generate QEMU's linker scripts? Ed Maste
2013-05-19 19:24 ` Paolo Bonzini
2013-05-20 0:22 ` Aurelien Jarno
2013-05-20 17:21 ` Richard Henderson
2013-05-21 17:51 ` Ed Maste
2013-05-21 18:14 ` Richard Henderson [this message]
2013-06-02 17:15 ` Peter Maydell
2013-06-03 14:23 ` Richard Henderson
2013-06-03 14:57 ` Peter Maydell
2013-06-03 15:01 ` Richard Henderson
2013-06-04 15:55 ` Claudio Fontana
2013-06-04 16:13 ` Peter Maydell
2013-06-04 16:18 ` Richard Henderson
2013-06-05 9:03 ` Claudio Fontana
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=519BB993.7070703@twiddle.net \
--to=rth@twiddle.net \
--cc=emaste@freebsd.org \
--cc=mjt@tls.msk.ru \
--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 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.