restructure results

1 files changed, 37 insertions, 0 deletions

diff --git a/results/classifier/zero-shot-user-mode/syscall/1516408 b/results/classifier/zero-shot-user-mode/syscall/1516408
new file mode 100644
index 000000000..41a1cba47
--- /dev/null
+++ b/results/classifier/zero-shot-user-mode/syscall/1516408
@@ -0,0 +1,37 @@
+syscall: 0.561
+instruction: 0.328
+runtime: 0.111
+
+
+
+sh4: Unsupported syscall: 186
+
+Hello!
+
+I'm currently testing qemu as a possibility to set up a buildd for the Debian sh4 port.
+
+I set up qemu and an sh4 chroot as described in the Debian Wiki [1]. This seems to be working mostly fine (besides the fact that qemu segfaults on an amd64 host while it runs fine on an i386 host, I'll file a separate bug report). However, when installing python3.4 in the sh4 chroot, qemu repeatedly printed an error message about an unimplemented syscall: 186:
+
+qemu: Unsupported syscall: 186
+
+From the source code in linux-user/sh4/syscall_nr.h it's apparent that 186 is defined as 
+
+#define TARGET_NR_sigaltstack   186
+
+Looking at the implementation part, it becomes obvious that this syscall is not enabled for sh4:
+
+#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \
+    defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || \
+    defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC)
+        ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState *)cpu_env));
+        break;
+#else
+        goto unimplemented;
+#endif
+
+Is there any particular reason why TARGET_NR_sigaltstack is not enabled on sh4? If not, could you enable it?
+
+Thanks,
+Adrian
+
+> [1] https://wiki.debian.org/QemuUserEmulation
\ No newline at end of file