> Were you able to replicate the problem with the steps that I had mentioned ? > The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow > the execution flow using "si" command of GDB. > You will definitely hit the problem.
Ah, I had to find a different gdb to reproduce this with (arm-none-eabi- gdb from the 2010.09 codesourcery toolchain). That gdb does single-step- insn by asking the target to single step, and you get the behaviour above. The gdb I was using does single-step-insn by setting breakpoints at where it thinks the next insn will be, which means that "si" on the UNDEF never returns because gdb has set a bp at 0x10005c which we of course never hit. With the codesourcery gdb I see 'si' having the behaviour you describe above. However: (gdb) target remote :1234 Remote debugging using :1234 0x00100000 in ?? () (gdb) break *0x4 Breakpoint 1 at 0x4 (gdb) si 0x00100054 in ?? () (gdb) si 0x00100058 in ?? () (gdb) si Breakpoint 1, 0x00000004 in ?? () ie if we set an explicit breakpoint at 0x4 we do hit it. I think it's just that the singlestep doesn't do what you expect: instead of stopping before we execute the instruction at the UNDEF vector, we first execute it and then stop afterwards [this sort of makes a twisted kind of sense if you think about it -- we never actually executed the UNDEF insn because we took the exception first, so single-step executes exactly one instruction which is the one at 0x4. However it's hopelessly confusing for the user so I'd consider it a bug.] Can you confirm that if you set the breakpoint as I do in the transcript above you see the same output? So I think that what is happening here is that misbehaviour by qemu's gdb interface is confusing you, rather than the actual qemu ARM implementation being wrong. If you revise your test program so that it installs some actual code into the vectors rather than leaving them all as NOPs I think this will be more obvious. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/757702 Title: Undefined instruction exception starts at offset 0x8 instead of 0x4 Status in QEMU: New Bug description: ARMv7a has lot of undefined instruction from its instruction opcode space. This undefined instructions are very useful for replacing sensitive non-priviledged instructions of guest operating systems (virtualization). The undefined instruction exception executes at <exception_base> + 0x4, where <exception_base> can be 0x0 or 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, seems like this is a new bug. As as example, if we try to execute value "0xec019800" in qemu 0.14.0 then it should cause undefined exception at <exception_base>+0x4 since "0xec019800" is an undefined instruction.
