semantic: 0.809
instruction: 0.784
socket: 0.773
mistranslation: 0.767
vnc: 0.731
network: 0.717
device: 0.711
KVM: 0.703
assembly: 0.701
graphic: 0.695
boot: 0.649
other: 0.582

ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it

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.

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.






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


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 <email address hidden>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
>


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
<email address hidden>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 <email address hidden>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
>>
>
>


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


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 <email address hidden>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
>


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
<email address hidden>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 <email address hidden>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
>>
>
>


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.


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


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 <email address hidden>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
>


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
<email address hidden>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 <email address hidden>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
>>
>
>


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
<email address hidden>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 <<email address hidden>
> > 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 <email address hidden>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
>>>
>>
>>
>


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


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 <email address hidden>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
>


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


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?

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

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


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