I think you are right. This seems to be more of a GDB issue. Any ways thanks for your support.
--Anup On Wed, Apr 13, 2011 at 5:24 PM, Peter Maydell <peter.mayd...@linaro.org>wrote: > > 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 direct subscriber > of the bug. > 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. > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/qemu/+bug/757702/+subscribe > -- 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.