Re: [Qemu-devel] [Bug 757702] Re: Undefined instruction exception starts at offset 0x8 instead of 0x4

[Anup Patel <757702@bugs.launchpad.net>]

Hi,

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.

--Anup

On Tue, Apr 12, 2011 at 5:57 PM, Anup Patel
<anuppatelinvincible@gmail.com>wrote:

> Try this out one last time. I am sure you will be able to replicate the
> problem.
>
> Run qemu like this:
> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S
>
> and run arm-none-gnueabi-gdb with no arguments and in gdb type these
> commands:
>
> (gdb) target remote :1234
> Remote debugging using :1234
> 0x00100000 in ?? ()
> (gdb) si
> 0x00100054 in ?? ()
> (gdb) si
> 0x00100054 in ?? ()
> (gdb) si
> 0x00000008 in ?? ()
>
> (I expect it to jump to 0x00000004 after 0x00100054)
>
> --Anup
>
> On Tue, Apr 12, 2011 at 5:40 PM, Anup Patel <anuppatelinvincible@gmail.com
> > wrote:
>
>> I see 0x00000008 ().
>>
>> I am using qemu-0.14.0.tar.gz available for QEMU Downloads.
>>
>> --Anup
>>
>>
>> On Tue, Apr 12, 2011 at 5:12 PM, Peter Maydell <peter.maydell@linaro.org>wrote:
>>
>>> > Also, in the test case hits 0x8 after encountering UNDEF instruction
>>> at 0x100058.
>>>
>>> So if you run qemu like this:
>>> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s
>>> -S
>>>
>>> and run arm-none-gnueabi-gdb with no arguments and in gdb type these
>>> commands:
>>>
>>> (gdb) target remote :1234
>>> Remote debugging using :1234
>>> 0x00100000 in ?? ()
>>> (gdb) break *0x4
>>> Breakpoint 1 at 0x4
>>> (gdb) break *0x8
>>> Breakpoint 2 at 0x8
>>> (gdb) c
>>> Continuing.
>>>
>>> ...what does gdb do?
>>> (For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I
>>> expect.)
>>>
>>> --
>>> 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.