diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/75 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/750 | 48 | ||||
| -rw-r--r-- | results/classifier/108/other/751 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/754 | 222 | ||||
| -rw-r--r-- | results/classifier/108/other/756 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/757 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/757654 | 64 | ||||
| -rw-r--r-- | results/classifier/108/other/757702 | 856 | ||||
| -rw-r--r-- | results/classifier/108/other/758 | 61 |
9 files changed, 1315 insertions, 0 deletions
diff --git a/results/classifier/108/other/75 b/results/classifier/108/other/75 new file mode 100644 index 00000000..32b4b8e2 --- /dev/null +++ b/results/classifier/108/other/75 @@ -0,0 +1,16 @@ +device: 0.873 +performance: 0.722 +graphic: 0.683 +semantic: 0.608 +network: 0.576 +other: 0.545 +files: 0.440 +PID: 0.366 +vnc: 0.296 +debug: 0.250 +boot: 0.242 +permissions: 0.174 +KVM: 0.136 +socket: 0.072 + +Add -display SDL grab-on-hover option diff --git a/results/classifier/108/other/750 b/results/classifier/108/other/750 new file mode 100644 index 00000000..dab15270 --- /dev/null +++ b/results/classifier/108/other/750 @@ -0,0 +1,48 @@ +graphic: 0.887 +network: 0.874 +semantic: 0.865 +vnc: 0.858 +files: 0.827 +device: 0.816 +debug: 0.776 +socket: 0.737 +PID: 0.688 +permissions: 0.635 +performance: 0.560 +boot: 0.528 +other: 0.505 +KVM: 0.113 + +/proc/cpuinfo doesn't present guest cpuinfo for most architectures (including M1 Macs) +Description of problem: +I tried to start Blender inside an amd docker container, emulated on M1 Mac, running noVNC to access the the GUI via Chrome. +From Blender versions 2.8 and higher I get the following error message: + +``` + ArchError: Could not find 'cpu MHz' in /proc/cpuinfo + Function: Arch_InitTickTimer + File: /home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/build/usd/src/external_usd/pxr/base/arch/timing.cpp + Line: 133 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +``` + +I posted the problem to Blender [here](https://developer.blender.org/T92956) as well as to docker [here](https://github.com/docker/for-mac/issues/6047). +Steps to reproduce: +You need: +- ✅ M1 Mac +- ✅ Docker Desktop 4.1.1 (69879) + +Setup the Container: + +1. Unzip the attached file +2. In a terminal go to the unzipped folder +3. run `source build-and-launch.sh` to build the image and spin up a container +4. open a browser and go to [http://localhost:6901](http://localhost:6901) +5. login using password `pass` +6. see the README.txt on the Desktop you just logged into +7. == Follow the README instructions == + + + +[blender-bug-report-202111091146.zip](/uploads/340ada45a9ee0585cfc0cdfcc1932fb4/blender-bug-report-202111091146.zip) diff --git a/results/classifier/108/other/751 b/results/classifier/108/other/751 new file mode 100644 index 00000000..1e618113 --- /dev/null +++ b/results/classifier/108/other/751 @@ -0,0 +1,16 @@ +device: 0.621 +socket: 0.393 +PID: 0.339 +semantic: 0.305 +boot: 0.301 +network: 0.295 +vnc: 0.289 +KVM: 0.201 +permissions: 0.193 +performance: 0.192 +files: 0.127 +graphic: 0.126 +debug: 0.109 +other: 0.088 + +Default set of CI tasks is quite broad for forks of non-developer respositories diff --git a/results/classifier/108/other/754 b/results/classifier/108/other/754 new file mode 100644 index 00000000..753c74e9 --- /dev/null +++ b/results/classifier/108/other/754 @@ -0,0 +1,222 @@ +other: 0.786 +permissions: 0.728 +debug: 0.649 +graphic: 0.638 +device: 0.636 +KVM: 0.629 +performance: 0.621 +vnc: 0.613 +semantic: 0.598 +socket: 0.580 +boot: 0.575 +PID: 0.571 +files: 0.548 +network: 0.499 + +qem_m68k : trapcs instruction causes the non-execution of the following 2 instructions +Description of problem: +In try to run following code : +``` +8004615a: 204f moveal %sp,%a0 +8004615c: b1c7 cmpal %d7,%a0 +8004615e: 55fc trapcs +80046160: 4e56 0000 linkw %fp,#0 +80046164: 2f14 movel %a4@,%sp@- +80046166: 288e movel %fp,%a4@ +80046168: c74d exg %a3,%a5 +8004616a: 48e7 3030 moveml %d2-%d3/%a2-%a3,%sp@- +8004616e: 7001 moveq #1,%d0 +80046170: 3b40 816c movew %d0,%a5@(-32404) +80046174: 7218 moveq #24,%d1 +80046176: 3b41 816a movew %d1,%a5@(-32406) +8004617a: 242d 8004 movel %a5@(-32764),%d2 +8004617e: 2b42 815c movel %d2,%a5@(-32420) +80046182: 206d 8008 moveal %a5@(-32760),%a0 +80046186: 2268 8010 moveal %a0@(-32752),%a1 +8004618a: 2b49 8158 movel %a1,%a5@(-32424) +8004618e: 42ad 8154 clrl %a5@(-32428) +80046192: 246d 8154 moveal %a5@(-32428),%a2 +80046196: 2b4a 8160 movel %a2,%a5@(-32416) +8004619a: 2b4a 8164 movel %a2,%a5@(-32412) +8004619e: 422d 8168 clrb %a5@(-32408) +800461a2: 7604 moveq #4,%d3 +800461a4: 2b43 8150 movel %d3,%a5@(-32432) +800461a8: 2668 8010 moveal %a0@(-32752),%a3 +800461ac: 2b4b 814c movel %a3,%a5@(-32436) +800461b0: 2268 8010 moveal %a0@(-32752),%a1 +800461b4: 266d 8008 moveal %a5@(-32760),%a3 +800461b8: 206b 8008 moveal %a3@(-32760),%a0 +800461bc: 4e90 jsr %a0@ +800461be: 2b48 8148 movel %a0,%a5@(-32440) +800461c2: 4cdf 0c0c moveml %sp@+,%d2-%d3/%a2-%a3 +800461c6: c74d exg %a3,%a5 +800461c8: 289f movel %sp@+,%a4@ +800461ca: 4e5e unlk %fp +800461cc: 4e75 rts +``` +When I run qemu-m68k -cpu m68020 -d in_asm,cpu, I have : +``` +---------------- +IN: +0x8004615a: moveal %sp,%a0 +0x8004615c: cmpal %d7,%a0 +0x8004615e: trapcs +0x80046160: linkw %fp,#0 +0x80046164: movel %a4@,%sp@- +0x80046166: movel %fp,%a4@ +0x80046168: exg %a3,%a5 +0x8004616a: moveml %d2-%d3/%a2-%a3,%sp@- +0x8004616e: moveq #1,%d0 +0x80046170: movew %d0,%a5@(-32404) +0x80046174: moveq #24,%d1 +0x80046176: movew %d1,%a5@(-32406) +0x8004617a: movel %a5@(-32764),%d2 +0x8004617e: movel %d2,%a5@(-32420) +0x80046182: moveal %a5@(-32760),%a0 +0x80046186: moveal %a0@(-32752),%a1 +0x8004618a: movel %a1,%a5@(-32424) +0x8004618e: clrl %a5@(-32428) +0x80046192: moveal %a5@(-32428),%a2 +0x80046196: movel %a2,%a5@(-32416) +0x8004619a: movel %a2,%a5@(-32412) +0x8004619e: clrb %a5@(-32408) +0x800461a2: moveq #4,%d3 +0x800461a4: movel %d3,%a5@(-32432) +0x800461a8: moveal %a0@(-32752),%a3 +0x800461ac: movel %a3,%a5@(-32436) +0x800461b0: moveal %a0@(-32752),%a1 +0x800461b4: moveal %a5@(-32760),%a3 +0x800461b8: moveal %a3@(-32760),%a0 +0x800461bc: jsr %a0@ + +Trace 0: 0x7f83a807e780 [00000000/8004615a/00000000/00000000] +D0 = 00000012 A0 = 8004615a F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd7000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC SR = 0004 T:0 I:0 UI --Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN + + +---------------- +IN: +0x80046358: lea %a1@(0,%d0:l),%a0 +0x8004635c: rts + +Trace 0: 0x7f83a807eac0 [00000000/80046358/00000000/00000000] +D0 = 00000001 A0 = 80046358 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000018 A1 = 00000000 F1 = 7fff ffffffffffffffff ( nan) +D2 = ffffffff A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000004 A3 = 8000c040 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 8000c3b0 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045fe0 F7 = 7fff ffffffffffffffff ( nan) +PC = 80046358 SR = 0004 T:0 I:0 UI --Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +``` +Stack pointer is 80045fe0, it should be 80045FD8. + +When I run with options -cpu m68020 -d in_asm,cpu,op -singlestep, I have : +``` +---------------- +IN: +0x8004615e: trapcs +0x80046160: linkw %fp,#0 +Disassembler disagrees with translator over instruction decoding +Please report this to qemu-devel@nongnu.org + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 8004615e 00000000 + mov_i32 tmp0,$0x0 + call flush_flags,$0x0,$0,env,CC_OP + setcond_i32 tmp2,CC_C,tmp0,ne + neg_i32 tmp2,tmp2 + mov_i32 tmp0,$0x56 + mov_i32 PC,$0x80046162 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7fba001a75c3 + +D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC = 8004615e SR = 0000 T:0 I:0 UI ----- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +IN: +0x80046162: orib #20,%d0 + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 80046162 00000000 + mov_i32 tmp0,$0x14 + ext8s_i32 tmp3,D0 + or_i32 tmp4,tmp3,tmp0 + and_i32 D0,D0,$0xffffff00 + ext8u_i32 tmp6,tmp4 + or_i32 D0,D0,tmp6 + ext8s_i32 CC_N,tmp4 + discard CC_C + discard CC_Z + discard CC_V + mov_i32 CC_OP,$0xb + mov_i32 PC,$0x80046166 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7fba001a7683 + +D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC = 80046162 SR = 0000 T:0 I:0 UI ----- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +IN: +0x80046166: movel %fp,%a4@ + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + +... +``` +I can see that instructions +``` +0x80046160: linkw %fp,#0 +0x80046164: movel %a4@,%sp@- +``` +are not executed +and an extra instruction +``` +0x80046162: orib #20,%d0 +``` +is executed +Steps to reproduce: +Run chroot qemu-m68k qemu-m68k-static -cpu m68020 -d in_asm,cpu -D log1.txt ./test +Additional information: + diff --git a/results/classifier/108/other/756 b/results/classifier/108/other/756 new file mode 100644 index 00000000..4752f039 --- /dev/null +++ b/results/classifier/108/other/756 @@ -0,0 +1,16 @@ +performance: 0.853 +device: 0.775 +debug: 0.747 +network: 0.541 +semantic: 0.395 +graphic: 0.393 +other: 0.378 +socket: 0.303 +vnc: 0.228 +boot: 0.182 +files: 0.159 +permissions: 0.146 +KVM: 0.122 +PID: 0.107 + +qemu-system-m68k -M q800 -bios /dev/null segfaults diff --git a/results/classifier/108/other/757 b/results/classifier/108/other/757 new file mode 100644 index 00000000..9616761b --- /dev/null +++ b/results/classifier/108/other/757 @@ -0,0 +1,16 @@ +device: 0.820 +performance: 0.787 +network: 0.599 +debug: 0.468 +graphic: 0.412 +semantic: 0.348 +boot: 0.301 +PID: 0.297 +socket: 0.226 +vnc: 0.217 +permissions: 0.192 +KVM: 0.182 +other: 0.170 +files: 0.109 + +intel-hda: stream reset bits are broken diff --git a/results/classifier/108/other/757654 b/results/classifier/108/other/757654 new file mode 100644 index 00000000..573fdfc2 --- /dev/null +++ b/results/classifier/108/other/757654 @@ -0,0 +1,64 @@ +device: 0.775 +performance: 0.748 +socket: 0.654 +other: 0.637 +vnc: 0.599 +semantic: 0.548 +network: 0.541 +graphic: 0.536 +permissions: 0.520 +boot: 0.454 +PID: 0.428 +KVM: 0.421 +debug: 0.408 +files: 0.372 + +UHCI fails to signal stall response + +When TD execution results in STALL error (STALL handshake, no stall as a result of err count reaching 0), there is no way to know about it except for checking that TD. IMO it is an error condition and it should be reflected in the status register (and issue an interrupt if enabled). + +Ways to replicate: +Send a query that is answered by stall (like set_idle request to a mouse) + +Expected behavior: +UHCI hc sets status bit 1 (usb error interrupt) and issues an interrupt + +current behavior: +Neither status bit is set nor interrupt triggered + +Version 0.14 +attached patch for current master (quick fix, it might be I got something wrong) + + + +Hi, + +Thanks for reporting this issue. + +Just so you are aware: the qemu USB maintainer is probably going to be away for a while longer, so don't be too worried if this patch doesn't get looked at for 2-4 weeks. + +Brad + + +No problem, it's not like it breaks something. This fix just makes driver development easier. + +On Thu, Apr 14, 2011 at 11:35 AM, jvesely <email address hidden> wrote: +> No problem, it's not like it breaks something. This fix just makes +> driver development easier. + +Please send your patch to the mailing list: + +http://wiki.qemu.org/Contribute/SubmitAPatch + +It may seem petty to ask this since you've already attached it to the +bug, but for QEMU development to scale and keep at a rapid pace, +everyone needs to follow these steps on submitting patches. Thanks +for your effort! + +Stefan + + +Patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8656954aedbd9995e68e +... so closing this ticket now. + diff --git a/results/classifier/108/other/757702 b/results/classifier/108/other/757702 new file mode 100644 index 00000000..c28e64f1 --- /dev/null +++ b/results/classifier/108/other/757702 @@ -0,0 +1,856 @@ +semantic: 0.809 +socket: 0.773 +debug: 0.763 +permissions: 0.760 +performance: 0.735 +vnc: 0.731 +network: 0.717 +device: 0.711 +PID: 0.707 +KVM: 0.703 +graphic: 0.695 +boot: 0.649 +files: 0.619 +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 + diff --git a/results/classifier/108/other/758 b/results/classifier/108/other/758 new file mode 100644 index 00000000..7a8c67e8 --- /dev/null +++ b/results/classifier/108/other/758 @@ -0,0 +1,61 @@ +other: 0.957 +graphic: 0.937 +permissions: 0.915 +debug: 0.899 +performance: 0.890 +semantic: 0.878 +device: 0.863 +KVM: 0.845 +vnc: 0.842 +network: 0.819 +files: 0.793 +socket: 0.744 +boot: 0.738 +PID: 0.727 + +[Cross compilation] qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Description of problem: +On the X86 platform, chroot to the latest MIP environment, download the source package, install the dependency, and then compile. It is found that the variation is in error + +Grab logs with GDB on the real machine + +Thread 1 "bash" received signal SIGSEGV, Segmentation fault. +0x00007f094429c656 in code_gen_buffer () +(gdb) bt +#0 0x00007f094429c656 in code_gen_buffer () +#1 0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353 +#2 0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812 +#3 cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970 +#4 0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78 +#5 0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910 +(gdb) thread apply all bt + +Thread 2 (LWP 26312): +#0 0x0000000000766a19 in syscall () +#1 0x000000000058ee0a in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at ./include/qemu/trace-events:29 +#2 qemu_event_wait (ev=ev@entry=0xd44e68 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:480 +#3 0x000000000059690a in call_rcu_thread (opaque=opaque@entry=0x0) at ./b/user-static/thread.h:258 +#4 0x000000000058dc29 in qemu_thread_start (args=<optimized out>) at ../../util/qemu-thread-posix.c:541 +#5 0x00000000006e665e in start_thread (arg=0x7f094c9a3640) at pthread_create.c:463 +#6 0x000000000076836f in clone () + +Thread 1 (LWP 26310): +#0 0x00007f094429c656 in code_gen_buffer () +#1 0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353 +#2 0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812 +#3 cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970 +#4 0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78 +#5 0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910 +(gdb) +``` +Steps to reproduce: +``` +1.Minimum environment for building MIPS platform on +2.On X86 platform sudo chroot . +3.cd build +4.apt source adwaita-icon-theme +5.cd adwaita-icon-theme-3.30.1 +6.debuild -b +``` +Additional information: + |