From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HeH51-0004Md-RZ for qemu-devel@nongnu.org; Wed, 18 Apr 2007 16:48:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HeH50-0004Lq-Av for qemu-devel@nongnu.org; Wed, 18 Apr 2007 16:48:43 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HeH4z-0004Ll-Vv for qemu-devel@nongnu.org; Wed, 18 Apr 2007 16:48:42 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HeH07-0000jY-9M for qemu-devel@nongnu.org; Wed, 18 Apr 2007 16:43:39 -0400 Message-ID: <462682F7.30600@mail.berlios.de> Date: Wed, 18 Apr 2007 22:43:35 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [Bug] Fatal error caused by wrong memory access References: <460FE571.2060000@mail.berlios.de> In-Reply-To: <460FE571.2060000@mail.berlios.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QEMU Developers Are there no comments? What is needed to get this fixed in QEMU CVS? Do you need additional information? Stefan Here is a quick hack patch for this problem: Index: cpu-exec.c =================================================================== RCS file: /sources/qemu/qemu/cpu-exec.c,v retrieving revision 1.100 diff -u -b -B -r1.100 cpu-exec.c --- cpu-exec.c 9 Apr 2007 22:45:36 -0000 1.100 +++ cpu-exec.c 18 Apr 2007 20:41:44 -0000 @@ -140,8 +140,12 @@ virt_page2 = (pc + tb->size - 1) & TARGET_PAGE_MASK; phys_page2 = -1; if ((pc & TARGET_PAGE_MASK) != virt_page2) { + if (tb->size == 0) { + printf("Bad code in QEMU %s:%u\n", __FILE__, __LINE__); + } else { phys_page2 = get_phys_addr_code(env, virt_page2); } + } tb_link_phys(tb, phys_pc, phys_page2); found: Stefan Weil schrieb: > 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