diff options
Diffstat (limited to 'results/classifier/deepseek-1/output/QEMU./757702')
| -rw-r--r-- | results/classifier/deepseek-1/output/QEMU./757702 | 842 |
1 files changed, 0 insertions, 842 deletions
diff --git a/results/classifier/deepseek-1/output/QEMU./757702 b/results/classifier/deepseek-1/output/QEMU./757702 deleted file mode 100644 index 9f38e13b..00000000 --- a/results/classifier/deepseek-1/output/QEMU./757702 +++ /dev/null @@ -1,842 +0,0 @@ - -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 - |