qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Loading ELF binaries with very high base addresses


From: Alexander Graf
Subject: Re: [Qemu-devel] Loading ELF binaries with very high base addresses
Date: Tue, 12 Jul 2011 18:43:49 +0200

Hi Prashant,


Am 12.07.2011 um 17:29 schrieb Prashant Vaibhav <address@hidden>:

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.

On x86_64 the high 16 bits of the virtual address space have to be equal - either 0x0000 or 0xffff. So the IA64 addresses can't be reflected in x86_64 virtual address space.

For now, you could try to add an ifdef that wraps around to some other lower address in the loop when the va is higher than x86_64 supports.


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?

I guess the long-term solution here really is to use the softmmu for linux-user as well - unless we're running 32-on-64.

For now, just force the mapping to somewhere mappable :)

Alex


reply via email to

[Prev in Thread] Current Thread [Next in Thread]