All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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 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.