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