>> >>> get_page_addr_code() reads a code tlb entry, but interprets it as an >> >>> iotlb entry. This works by accident since the low bits of a RAM code >> >>> tlb entry are clear, and match a RAM iotlb entry. This accident is >> >>> about to unhappen, so fix the code to use an iotlb entry (using the >> >>> code entry with TLB_MMIO may fail if the page is a watchpoint). >> >>> >> >>> Signed-off-by: Avi Kivity<a...@redhat.com> >> >>> --- >> >>> exec.c | 2 +- >> >>> 1 files changed, 1 insertions(+), 1 deletions(-) >> >>> >> >>> diff --git a/exec.c b/exec.c >> >>> index a35eb4f..f26d1b0 100644 >> >>> --- a/exec.c >> >>> +++ b/exec.c >> >>> @@ -4685,7 +4685,7 @@ tb_page_addr_t get_page_addr_code(CPUState >> >>> *env1, target_ulong addr) >> >>> (addr& TARGET_PAGE_MASK))) { >> >>> ldub_code(addr); >> >>> } >> >>> - pd = env1->tlb_table[mmu_idx][page_index].addr_code& >> >>> ~TARGET_PAGE_MASK; >> >>> + pd = env1->iotlb[mmu_idx][page_index]& ~TARGET_PAGE_MASK; >> >>> if (pd != io_mem_ram.ram_addr&& pd != io_mem_rom.ram_addr >> >>> && !io_mem_region[pd]->rom_device) { >> >>> #if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || >> >>> defined(TARGET_SPARC) >> >> >> >> With this patch xtensa debug option unit test causes qemu abort with >> >> the message >> >> >> >> qemu: fatal: Trying to execute code outside RAM or ROM at 0xd000088c >> >> >> >> This happens immediately after a watchpoint setup for a data >> >> breakpoint at the same memory page where the currently >> >> executed code is located. Any idea on how to fix it? >> > >> > Can you provide details on how to reproduce this? >> >> It may be reproduced by running test_break.tst unit test: >> >> qemu-system-xtensa -M sim -cpu dc232b -nographic -semihosting -kernel >> ./test_break.tst >> >> Compiled test binary is here: >> http://jcmvbkbc.spb.ru/~dumb/ws/osll/qemu-xtensa/20120318/test_break.tst >> > > Thanks. Please try out the attached patch.
Thanks, with this patch it works. -- Max