From: Stefan Weil <weil@mail.berlios.de>
To: QEMU Developers <qemu-devel@nongnu.org>
Subject: [Qemu-devel] [Bug] Fatal error caused by wrong memory access
Date: Sun, 01 Apr 2007 19:01:37 +0200 [thread overview]
Message-ID: <460FE571.2060000@mail.berlios.de> (raw)
When the program counter is at the very start of a memory block
amd there is no page allocated before this block, QEMU may fail
with a fatal error ("Trying to execute code outside RAM or ROM").
In my case, a MIPS system had code in flash starting at 0xb0000000.
I had a remote debugger attached to the emulated MIPS system and
set a breakpoint at 0xb0000000. When the breakpoint is reached,
QEMU terminates while accessing 0xaffff000 (start of page before
the breakpoint). No crash occurs when the breakpoint is set at
0xb0000004 or higher addresses or without a breakpoint.
A first workaround was to allocate a special page for the debugger
at 0xaffff000. Then I examined the problem and saw that it was not
caused by the debugger but by QEMU. This code at cpu-exec.c:138
triggers the fatal error:
/* check next page if needed */
virt_page2 = (pc + tb->size - 1) & TARGET_PAGE_MASK;
phys_page2 = -1;
if ((pc & TARGET_PAGE_MASK) != virt_page2) {
phys_page2 = get_phys_addr_code(env, virt_page2);
}
tb_link_phys(tb, phys_pc, phys_page2);
In my case, tb->size == 0, so virt_page2 is an invalid page just
before the first valid page. This triggers the fatal error in
get_phys_addr_code. This might occur for any architecture.
A quick hack could check for tb->size == 0, but maybe there is a
better solution...
Stefan
next reply other threads:[~2007-04-01 17:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-01 17:01 Stefan Weil [this message]
2007-04-18 20:43 ` [Qemu-devel] [Bug] Fatal error caused by wrong memory access Stefan Weil
2007-11-30 22:46 ` [Qemu-devel] [Bug][PATCH] " Stefan Weil
2007-12-12 0:29 ` andrzej zaborowski
2007-12-12 19:36 ` Stefan Weil
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=460FE571.2060000@mail.berlios.de \
--to=weil@mail.berlios.de \
--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).