diff options
Diffstat (limited to 'results/classifier/111/review/757702')
| -rw-r--r-- | results/classifier/111/review/757702 | 870 |
1 files changed, 870 insertions, 0 deletions
diff --git a/results/classifier/111/review/757702 b/results/classifier/111/review/757702 new file mode 100644 index 00000000..a16cbbf1 --- /dev/null +++ b/results/classifier/111/review/757702 @@ -0,0 +1,870 @@ +semantic: 0.119 +socket: 0.094 +permissions: 0.094 +device: 0.077 +PID: 0.073 +vnc: 0.071 +files: 0.067 +debug: 0.066 +other: 0.064 +boot: 0.061 +network: 0.058 +KVM: 0.057 +performance: 0.055 +graphic: 0.046 +debug: 0.276 +semantic: 0.155 +files: 0.107 +PID: 0.083 +other: 0.069 +device: 0.061 +boot: 0.040 +socket: 0.038 +network: 0.038 +performance: 0.035 +vnc: 0.033 +KVM: 0.027 +graphic: 0.020 +permissions: 0.018 + +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 + |