1 files changed, 45 insertions, 0 deletions
diff --git a/results/classifier/118/none/1353346 b/results/classifier/118/none/1353346
new file mode 100644
index 00000000..82134d27
--- /dev/null
+++ b/results/classifier/118/none/1353346
@@ -0,0 +1,45 @@
+device: 0.761
+arm: 0.681
+architecture: 0.680
+graphic: 0.636
+register: 0.619
+vnc: 0.574
+mistranslation: 0.541
+performance: 0.532
+ppc: 0.509
+socket: 0.479
+network: 0.468
+kernel: 0.431
+semantic: 0.402
+risc-v: 0.360
+boot: 0.344
+peripherals: 0.332
+permissions: 0.304
+files: 0.292
+user-level: 0.239
+VMM: 0.233
+debug: 0.229
+virtual: 0.218
+TCG: 0.166
+hypervisor: 0.138
+PID: 0.130
+assembly: 0.118
+x86: 0.116
+i386: 0.098
+KVM: 0.094
+
+ARMv7-M software-triggered interrupts-- unexpected behaviour
+
+The handling of the NVIC "Software Triggered Interrupt Register" in qemu-2.1.0/hw/intc/armv7m_nvic.c:375 isn't quite right.  As things stand, writing a zero to the STIR ends up transferring control to vector table entry zero, which, on ARMv7-M, holds the reset value of the stack pointer.  That's what I see with lm3s811evb emulation, and that's not what happens on my STM NUCLEO-F103RB board (Cortex-M3).
+
+Seems like an oversight-- the handler probably wants armv7m_nvic_set_pending(), not gic_set_pending_private(), and the IRQ number needs 16 added onto it to get the exception number for the interrupt.
+
+ARM DUI 0552A (Cortex-M3 Devices: Generic User's Guide), p. 134:
+  "Interrupt ID of the interrupt to trigger, in the range 0-239. For example, a value of 0x03 specifies interrupt IRQ3."
+
+Cheers,
+Boris
+
+This bug was fixed in QEMU 2.9 as part of the rewrite of M profile exception handling.
+
+