From: "Alexandre Pereira Nunes" <alexandre.nunes@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] qemu user mode & ELF binaries with vma != lma
Date: Fri, 7 Dec 2007 12:37:48 -0200 [thread overview]
Message-ID: <3b6faf240712070637o19c63954ub0e45567deccefb4@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2121 bytes --]
next reply other threads:[~2007-12-07 14:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-07 14:37 Alexandre Pereira Nunes [this message]
2007-12-07 15:26 ` [Qemu-devel] qemu user mode & ELF binaries with vma != lma Paul Brook
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=3b6faf240712070637o19c63954ub0e45567deccefb4@mail.gmail.com \
--to=alexandre.nunes@gmail.com \
--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 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).