From: "\"Marc Lörner\"" <loerner@gmx.de>
To: qemu@mercurysquad.com, qemu-devel@nongnu.org
Cc: agraf@suse.de
Subject: Re: [Qemu-devel] Loading ELF binaries with very high base addresses
Date: Tue, 12 Jul 2011 19:14:19 +0200 [thread overview]
Message-ID: <20110712171419.119190@gmx.net> (raw)
Hello Prashant,
first of all your "0x4<<64" is wrong it's "0x4<<60".
In Volume 2 of the IASDM page 2:46 you see that these three upper bits
correspond to the 8 virtual regions (here: region 2).
So maybe you can just disregard these bits and use the rest as new offset
to an faked guest_base that fits your needs (e.g. somewhere in your
process space)?
Regards,
Marc
>Hello,
>
>I am working on target-ia64, but am stuck during ia64 ELF loading.
>
>Referring to function "probe_guest_base()" in linux-user/elfload.c around >line 1350, called from around line 1484 --
>
>When the main binary is being mmap'd, the host address and guest address >should ideally be the same. If they're not, a linear search is done by >increasing the host_address by one page and trying the mmap again. The
>(positive) offset is then saved.
>The problem occurs with ia64 binaries, which typically start at >0x4000000000000000 (i.e 0x4<<64). At least on my x86_64 host machine, >mmap'ing at this address fails. The real_address is of the order of >0x8<<32. Needless to say, increasing host_address and trying again will >never reach a lower address to map at. Further, I cannot make it relocate >to a lower host address because the offset (guest_base) is an unsigned >int and so the relocation can only happen by a positive offset.
>
>Because of this it is not possible to load any ELF binaries which start >at such high memory addresses. I can tailor an elf binary to start at a >lower base address, which might work for that specific case, but I >suspect most existing ia64 binaries start at 0x4<<64 by convention. Also, >the "hiaddr" is read from elf header which again is set to 0x4<<64 + some >value.
>
>The existing code works fine with x86_64, for example, because the >binaries are typically starting at 0x40000, which is easily mmap'd at >first try.
>
>Any ideas on a workaround?
>
>~Prashant
--
NEU: FreePhone - kostenlos mobil telefonieren!
Jetzt informieren: http://www.gmx.net/de/go/freephone
next reply other threads:[~2011-07-12 17:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-12 17:14 "Marc Lörner" [this message]
2011-07-12 18:19 ` [Qemu-devel] Loading ELF binaries with very high base addresses Prashant Vaibhav
-- strict thread matches above, loose matches on Subject: below --
2011-07-12 15:29 Prashant Vaibhav
2011-07-12 16:43 ` Alexander Graf
2011-07-12 18:34 ` Richard Henderson
2011-07-12 20:58 ` Prashant Vaibhav
2011-07-12 21:32 ` Richard Henderson
2011-07-13 1:14 ` Prashant Vaibhav
2011-07-12 19:17 ` 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=20110712171419.119190@gmx.net \
--to=loerner@gmx.de \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=qemu@mercurysquad.com \
/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).