qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] qemu user mode & ELF binaries with vma != lma


From: Alexandre Pereira Nunes
Subject: [Qemu-devel] qemu user mode & ELF binaries with vma != lma
Date: Fri, 7 Dec 2007 12:37:48 -0200

Hi,

I'm attempting to use qemu-user-arm in a very weird way:

I'm using it to simulate a firmware image for an arm mcu. I only need to emulate the arm core, not specific periferals (I'm use semihosting to interact with an abstraction level).

I use the same ELF file resulted from the process (I'm using the gnuarm toolset, with a custom entry routine and a custom link script).

Everything works fine, except that the entry points attempts to copy memory from what it believes to be the "rom" image and the ram segment. The thing is that qemu already does that itself, because it looks at my data segment in the elf file and puts it at the right virtual address (what on the microcontroller would be the ram area). But that's not a problem: I could let the entry point copy it again by itself. But qemu does not map the data segment on the physical address area, so the startup code ends up reading the remaning of the  code segment (where it believes it will find the original data segment) until the page boundary, where it segfaults.

I looked at elfload.c, and found in the function load_elf_binary(...) where it maps the segments, and at the same time it seemed trivial to do the trick of mapping the segment twice (once as a read-only segment, mapped to the physical area [p_paddr], and once as it already is, or just creating a fresh mapping at the virtual address).

However after this first impression I got a bit confused. If someone could tip me on how to achieve that, I would appreciate.

If there are other ways to do that without modifying the entry loader (I have strong reasons to keep it intact, believe me), I'm open to suggestions as well.

Before someone points me to the system qemu (I know that what I'm trying to do is quite non-standard use of the software), I must say it would not be quite as handy as using the user one, specially in automated tests where there's no user intervention. It already does everything I need, except this little thing.

Thanks,

Alexandre



reply via email to

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