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

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

[Anup Patel]

Public bug reported:

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.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
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.

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

[Peter Maydell]

I can't reproduce this (either with current trunk or with qemu 0.14.0
release version). Also, if we were directing UNDEF exceptions to the SVC
entry point I think it would cause fairly obvious breakage of Linux
guests.

I'm going to attach the test program I used to confirm that we are
correctly directing the exception to the 0x4 vector:

./arm-softmmu/qemu-system-arm -kernel ~/linaro/qemu-misc-tests/undef-exc.axf  -semihosting
Starting test
In undef vector

I'll also attach the binary, since it's only 2K and the source needs
armcc to build.

If you can provide a simple test program and qemu command line which
demonstrates the behaviour you think is incorrect I can investigate
further.

-- 
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.

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

[Peter Maydell]

** Attachment added: "test program (source)"
   https://bugs.launchpad.net/qemu/+bug/757702/+attachment/2023202/+files/undef-exc.s

-- 
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.

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

[Peter Maydell]

** Attachment added: "test program (ELF binary)"
   https://bugs.launchpad.net/qemu/+bug/757702/+attachment/2023214/+files/undef-exc.axf

-- 
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.

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

[Peter Maydell]

> 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). 

PS: please don't use arbitrary UNDEF instruction patterns for this (the one you quoted is in the STC instruction space  for example). There's an officially-defined "permanently UNDEF" space:
 cond 0111 1111 xxxx xxxx xxxx 1111 xxxx
available for this purpose, which will mean you don't have to worry about newer versions of the architecture allocating the UNDEF patterns you were using.

-- 
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.

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

[Anup Patel]

Hi,

You are right, I have deliberately used an instruction from a "permanently
UNDEF" space. I have used this instruction because thats this are the only
UNDEF instructions with maximum payload of 20 bits.

Also, the instruction "0xec019800" does not belong to STC instruction space.
GNU object dump does not display it as undefined instruction due to internal
bug, but it is definitely an undefined instruction.
May be the undefined instructions from "permanently UNDEF" space are only
executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU
0.13.0.

PFA, my test elf file. The UNDEF instruction that i have reported is
at location 0x100058 in this elf file. The execution of elf file starts from
0x100000.

I have launched qemu with command: ./qemu-system-arm -s -S -M realview-pb-a8
-serial stdio -kernel ../../../xvisor/tests/armv7/pb-a8/arm_test.elf
I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf
--eval-command="target remote localhost:1234"

Please let me know if you are not able to reproduce the bug.

--Anup

On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell
<peter.maydell@linaro.org>wrote:

> > 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).
>
> PS: please don't use arbitrary UNDEF instruction patterns for this (the one
> you quoted is in the STC instruction space  for example). There's an
> officially-defined "permanently UNDEF" space:
>  cond 0111 1111 xxxx xxxx xxxx 1111 xxxx
> available for this purpose, which will mean you don't have to worry about
> newer versions of the architecture allocating the UNDEF patterns you were
> using.
>
> --
> 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
>


** Attachment added: "arm_test.elf"
   https://bugs.launchpad.net/bugs/757702/+attachment/2023365/+files/arm_test.elf

-- 
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.

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

[Anup Patel]

Hi

The correct command to launch qemu will be: ./qemu-system-arm -s -S -M
realview-pb-a8 -serial stdio -kernel arm_test.elf
Sorry, for mistake in previous mail.

--Anup

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

> Hi,
>
> You are right, I have deliberately used an instruction from a "permanently
> UNDEF" space. I have used this instruction because thats this are the only
> UNDEF instructions with maximum payload of 20 bits.
>
> Also, the instruction "0xec019800" does not belong to STC instruction
> space. GNU object dump does not display it as undefined instruction due to
> internal bug, but it is definitely an undefined instruction.
> May be the undefined instructions from "permanently UNDEF" space are only
> executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU
> 0.13.0.
>
> PFA, my test elf file. The UNDEF instruction that i have reported is
> at location 0x100058 in this elf file. The execution of elf file starts from
> 0x100000.
>
> I have launched qemu with command: ./qemu-system-arm -s -S -M
> realview-pb-a8 -serial stdio -kernel
> ../../../xvisor/tests/armv7/pb-a8/arm_test.elf
> I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf
> --eval-command="target remote localhost:1234"
>
> Please let me know if you are not able to reproduce the bug.
>
> --Anup
>
> On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell <peter.maydell@linaro.org>wrote:
>
>> > 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).
>>
>> PS: please don't use arbitrary UNDEF instruction patterns for this (the
>> one you quoted is in the STC instruction space  for example). There's an
>> officially-defined "permanently UNDEF" space:
>>  cond 0111 1111 xxxx xxxx xxxx 1111 xxxx
>> available for this purpose, which will mean you don't have to worry about
>> newer versions of the architecture allocating the UNDEF patterns you were
>> using.
>>
>> --
>> 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.

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

[Peter Maydell]

> Also, the instruction "0xec019800" does not belong to STC instruction
space.

Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 imm:8
For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in STC space. This is not "permanently UNDEF", it might be allocated to do something in future.

> PFA, my test elf file.

Thanks. Your test case appears to be broken in that it doesn't actually set up the vector table at address 0:
cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble ~/Desktop/arm_test.elf |less

[...]
Disassembly of section .text:

00100000 <_start_vect>:
  100000:       e59ff018        ldr     pc, [pc, #24]   ; 100020 <__reset>
  100004:       e59ff018        ldr     pc, [pc, #24]   ; 100024 <__undefined_instruction>
  100008:       e59ff018        ldr     pc, [pc, #24]   ; 100028 <__software_interrupt>
  10000c:       e59ff018        ldr     pc, [pc, #24]   ; 10002c <__prefetch_abort>
  100010:       e59ff018        ldr     pc, [pc, #24]   ; 100030 <__data_abort>
  100014:       e59ff018        ldr     pc, [pc, #24]   ; 100034 <__not_used>
  100018:       e59ff018        ldr     pc, [pc, #24]   ; 100038 <__irq>
  10001c:       e59ff018        ldr     pc, [pc, #24]   ; 10003c <__fiq>

So what happens is:
0x00100000:  e59ff018      ldr  pc, [pc, #24]   # qemu starts us at the ELF entry point
0x00100054:  e3a08000      mov  r8, #0  ; 0x0 
0x00100054:  e3a08000      mov  r8, #0  ; 0x0
0x00100058:  ec019800      stc  8, cr9, [r1], {0}   # here's our UNDEF
0x00000004:  00000000      andeq        r0, r0, r0   # jump to UNDEF vector at 0x4 as expected
...but since nothing was loaded at address 0 the code is all NOPs and we just execute through it...
0x00000008:  00000000      andeq        r0, r0, r0
0x0000000c:  00000000      andeq        r0, r0, r0
0x00000010:  00000000      andeq        r0, r0, r0
...etc...

and eventually we fall into the actual image start at 0x100000, and we
go round in a big loop.

You can tell we're going to the correct vector if you ask gdb to put a
breakpoint there with "break *0x4" -- we hit it after executing the
undef.

-- 
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.

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

[Anup Patel]

Actually, the undefined instruction that I have used is documented as
undefined at two places in "ARM Instruction Set Encoding" section of ARMv7a
reference manual:
1. Refer "Table A5-22 Supervisor Call, and coprocessor instructions"
2. Refer "A8.6.188 STC, STC2"

So you see one can easily get confused that this instruction belongs to STC
space. Actually speaking this UNDEF instruction spans not only in STC space
but also in LDC space.

--Anup

On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell
<peter.maydell@linaro.org>wrote:

> > Also, the instruction "0xec019800" does not belong to STC instruction
> space.
>
> Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4
> imm:8
> For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in
> STC space. This is not "permanently UNDEF", it might be allocated to do
> something in future.
>
> > PFA, my test elf file.
>
> Thanks. Your test case appears to be broken in that it doesn't actually set
> up the vector table at address 0:
> cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble
> ~/Desktop/arm_test.elf |less
>
> [...]
> Disassembly of section .text:
>
> 00100000 <_start_vect>:
>  100000:       e59ff018        ldr     pc, [pc, #24]   ; 100020 <__reset>
>  100004:       e59ff018        ldr     pc, [pc, #24]   ; 100024
> <__undefined_instruction>
>  100008:       e59ff018        ldr     pc, [pc, #24]   ; 100028
> <__software_interrupt>
>  10000c:       e59ff018        ldr     pc, [pc, #24]   ; 10002c
> <__prefetch_abort>
>  100010:       e59ff018        ldr     pc, [pc, #24]   ; 100030
> <__data_abort>
>  100014:       e59ff018        ldr     pc, [pc, #24]   ; 100034
> <__not_used>
>  100018:       e59ff018        ldr     pc, [pc, #24]   ; 100038 <__irq>
>  10001c:       e59ff018        ldr     pc, [pc, #24]   ; 10003c <__fiq>
>
> So what happens is:
> 0x00100000:  e59ff018      ldr  pc, [pc, #24]   # qemu starts us at the ELF
> entry point
> 0x00100054:  e3a08000      mov  r8, #0  ; 0x0
> 0x00100054:  e3a08000      mov  r8, #0  ; 0x0
> 0x00100058:  ec019800      stc  8, cr9, [r1], {0}   # here's our UNDEF
> 0x00000004:  00000000      andeq        r0, r0, r0   # jump to UNDEF vector
> at 0x4 as expected
> ...but since nothing was loaded at address 0 the code is all NOPs and we
> just execute through it...
> 0x00000008:  00000000      andeq        r0, r0, r0
> 0x0000000c:  00000000      andeq        r0, r0, r0
> 0x00000010:  00000000      andeq        r0, r0, r0
> ...etc...
>
> and eventually we fall into the actual image start at 0x100000, and we
> go round in a big loop.
>
> You can tell we're going to the correct vector if you ask gdb to put a
> breakpoint there with "break *0x4" -- we hit it after executing the
> undef.
>
> --
> 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.

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

[Anup Patel]

Also, in the test case hits 0x8 after encountering UNDEF instruction at
0x100058.
The test case is not broken it failed in initialization sequence itself.

PS: I had download most recent version of QEMU 0.14.0 and build it my
self.

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

> Actually, the undefined instruction that I have used is documented as
> undefined at two places in "ARM Instruction Set Encoding" section of ARMv7a
> reference manual:
> 1. Refer "Table A5-22 Supervisor Call, and coprocessor instructions"
> 2. Refer "A8.6.188 STC, STC2"
>
> So you see one can easily get confused that this instruction belongs to STC
> space. Actually speaking this UNDEF instruction spans not only in STC space
> but also in LDC space.
>
> --Anup
>
> On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell <peter.maydell@linaro.org>wrote:
>
>> > Also, the instruction "0xec019800" does not belong to STC instruction
>> space.
>>
>> Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4
>> imm:8
>> For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in
>> STC space. This is not "permanently UNDEF", it might be allocated to do
>> something in future.
>>
>> > PFA, my test elf file.
>>
>> Thanks. Your test case appears to be broken in that it doesn't actually
>> set up the vector table at address 0:
>> cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble
>> ~/Desktop/arm_test.elf |less
>>
>> [...]
>> Disassembly of section .text:
>>
>> 00100000 <_start_vect>:
>>  100000:       e59ff018        ldr     pc, [pc, #24]   ; 100020 <__reset>
>>  100004:       e59ff018        ldr     pc, [pc, #24]   ; 100024
>> <__undefined_instruction>
>>  100008:       e59ff018        ldr     pc, [pc, #24]   ; 100028
>> <__software_interrupt>
>>  10000c:       e59ff018        ldr     pc, [pc, #24]   ; 10002c
>> <__prefetch_abort>
>>  100010:       e59ff018        ldr     pc, [pc, #24]   ; 100030
>> <__data_abort>
>>  100014:       e59ff018        ldr     pc, [pc, #24]   ; 100034
>> <__not_used>
>>  100018:       e59ff018        ldr     pc, [pc, #24]   ; 100038 <__irq>
>>  10001c:       e59ff018        ldr     pc, [pc, #24]   ; 10003c <__fiq>
>>
>> So what happens is:
>> 0x00100000:  e59ff018      ldr  pc, [pc, #24]   # qemu starts us at the
>> ELF entry point
>> 0x00100054:  e3a08000      mov  r8, #0  ; 0x0
>> 0x00100054:  e3a08000      mov  r8, #0  ; 0x0
>> 0x00100058:  ec019800      stc  8, cr9, [r1], {0}   # here's our UNDEF
>> 0x00000004:  00000000      andeq        r0, r0, r0   # jump to UNDEF
>> vector at 0x4 as expected
>> ...but since nothing was loaded at address 0 the code is all NOPs and we
>> just execute through it...
>> 0x00000008:  00000000      andeq        r0, r0, r0
>> 0x0000000c:  00000000      andeq        r0, r0, r0
>> 0x00000010:  00000000      andeq        r0, r0, r0
>> ...etc...
>>
>> and eventually we fall into the actual image start at 0x100000, and we
>> go round in a big loop.
>>
>> You can tell we're going to the correct vector if you ask gdb to put a
>> breakpoint there with "break *0x4" -- we hit it after executing the
>> undef.
>>
>> --
>> 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.

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

[Peter Maydell]

Sorry, I didn't notice the footnote in table A5-22; I see what you mean
now. It's still not permanently-UNDEF space though and you'd really be
better off using that instead. In any case, qemu does properly UNDEF the
instruction so this is a bit of a diversion.

-- 
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.

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

[Peter Maydell]

> 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 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.

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

[Anup Patel]

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.

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

[Anup Patel]

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.

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

[Anup Patel]

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.

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

[Peter Maydell]

> 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.

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

[Anup Patel]

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.maydell@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.

[Qemu-devel] [Bug 757702] Re: ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

[Peter Maydell]

> I think you are right. This seems to be more of a GDB issue.

The debug stub is still part of QEMU, so let's not close this bug just
yet :-)


** Summary changed:

- Undefined instruction exception starts at offset 0x8 instead of 0x4
+ ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

-- 
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:
  ARM: singlestepping insn which UNDEFs should stop at UNDEF vector
  insn, not after it

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.

[Qemu-devel] [Bug 757702] Re: ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

[Thomas Huth]

Triaging old bug tickets ... can you somehow still reproduce this
problem with the latest version of QEMU (currently v2.9), or could we
close this ticket nowadays?

** Changed in: qemu
       Status: New => Incomplete

-- 
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:
  ARM: singlestepping insn which UNDEFs should stop at UNDEF vector
  insn, not after it

Status in QEMU:
  Incomplete

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 manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/757702/+subscriptions

[Qemu-devel] [Bug 757702] Re: ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
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:
  ARM: singlestepping insn which UNDEFs should stop at UNDEF vector
  insn, not after it

Status in QEMU:
  Expired

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 manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/757702/+subscriptions

[Qemu-devel] [Bug 757702] Re: ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

[Peter Maydell]

This is still a bug, we shouldn't have let it expire.


** Changed in: qemu
       Status: Expired => Confirmed

-- 
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:
  ARM: singlestepping insn which UNDEFs should stop at UNDEF vector
  insn, not after it

Status in QEMU:
  Confirmed

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 manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/757702/+subscriptions

[Bug 757702] Re: ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

[Thomas Huth]

Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ba3c35d9c4026361fd3

** Changed in: qemu
       Status: Confirmed => Fix Released

-- 
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:
  ARM: singlestepping insn which UNDEFs should stop at UNDEF vector
  insn, not after it

Status in QEMU:
  Fix Released

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 manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/757702/+subscriptions