add manually reviewed semantic bugs

1 files changed, 73 insertions, 0 deletions

diff --git a/results/classifier/semantic-bugs/instruction/1926759 b/results/classifier/semantic-bugs/instruction/1926759
new file mode 100644
index 000000000..753b9e4d4
--- /dev/null
+++ b/results/classifier/semantic-bugs/instruction/1926759
@@ -0,0 +1,73 @@
+instruction: 0.938
+semantic: 0.770
+graphic: 0.694
+other: 0.656
+device: 0.644
+vnc: 0.552
+assembly: 0.506
+socket: 0.491
+network: 0.398
+boot: 0.365
+mistranslation: 0.349
+KVM: 0.297
+
+WFI instruction results in unhandled CPU exception
+
+Hi 
+
+I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following  crash log.
+
+qemu: unhandled CPU exception 0x10001 - aborting
+R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec
+R04=00010a28 R05=00010158 R06=00087460 R07=00010158
+R08=00000000 R09=00000000 R10=00085b7c R11=408009f4
+R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8
+PSR=60000010 -ZC- A usr32
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12
+
+WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks.
+
+Regards
+Muhui
+
+Please provide a test case binary and your QEMU command line.
+
+
+Oh, and the QEMU version you're using as well, please.
+
+
+cmd： ~/qemu-5.1.0/arm-linux-user/qemu-arm ~/test2
+
+QEMU version: qemu-arm version 5.1.0
+
+Sorry that I didn't test it on the latest version of QEMU.
+
+Crash repros on current QEMU.
+
+This is a bug, in that we shouldn't crash like this. However, it doesn't really make any sense for a userspace program (which is what a binary run by qemu-arm is) to execute the WFI instruction, which is largely intended for OSes to use. If your guest binary needs to use WFI, you should probably be running it on the system emulation QEMU, which does handle WFI correctly.
+
+
+The aarch64 kernel traps and handles WFI as a NOP: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c219bc4e9205 -- so that's probably the most sensible implementation for our linux-user mode. (The aarch32 kernel doesn't trap it, yet, but 
+"WFI is a NOP" is a valid architectural implementation anyway.)
+
+
+I agree with this implementation. Though WFI seems make no sense for a userspace program, we should not have assumption that the userspace program will not use this instruction. 
+
+It seems ARM manual does not defined the implementation of function EnterLowPowerState();  However, before executing this instruction, there are some checks like below:
+
+if PSTATE.EL == EL0 then
+     // Check for traps described by the OS which may be EL1 or EL2.
+     AArch32.CheckForWFxTrap(EL1, FALSE);
+
+I am not sure whether it is complex/required to implement this in QEMU. Maybe patch the WFI as a NOP looks like the best idea at this moment.
+
+We do implement those traps, but only in the system mode emulator, because it makes no sense to trap to EL2 in the usermode emulator where EL2 doesn't exist.
+
+
+Should be fixed by:
+https://<email address hidden>/
+
+
+Fix has been merged:
+https://gitlab.com/qemu-project/qemu/-/commit/5b2c8af89b82a671137a
+