What about my bug report? Up to now I got no replies. Please include the patch in CVS HEAD - or tell me why you won't do so.
Kind regards Stefan Stefan Weil schrieb: > 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 >> and 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
Index: cpu-exec.c =================================================================== RCS file: /sources/qemu/qemu/cpu-exec.c,v retrieving revision 1.126 diff -u -r1.126 cpu-exec.c --- cpu-exec.c 23 Nov 2007 02:11:10 -0000 1.126 +++ cpu-exec.c 30 Nov 2007 22:43:22 -0000 @@ -140,7 +140,11 @@ 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);