restructure results

6 files changed, 0 insertions, 449 deletions

diff --git a/results/classifier/016/assembly-x86/1156313 b/results/classifier/016/assembly-x86/1156313
deleted file mode 100644
index f3c30a2a..00000000
--- a/results/classifier/016/assembly-x86/1156313
+++ /dev/null
@@ -1,147 +0,0 @@
-x86: 0.943
-assembly: 0.861
-operating system: 0.178
-debug: 0.028
-files: 0.011
-TCG: 0.007
-kernel: 0.006
-hypervisor: 0.006
-register: 0.005
-user-level: 0.004
-architecture: 0.004
-semantic: 0.003
-PID: 0.002
-device: 0.002
-performance: 0.002
-virtual: 0.002
-VMM: 0.001
-boot: 0.001
-KVM: 0.001
-risc-v: 0.001
-vnc: 0.001
-graphic: 0.001
-permissions: 0.000
-socket: 0.000
-ppc: 0.000
-network: 0.000
-peripherals: 0.000
-mistranslation: 0.000
-alpha: 0.000
-i386: 0.000
-arm: 0.000
-
-X86-64 flags handling broken
-
-The current qemu sources cause improper handling of flags on x86-64.
-This bug seems to have shown up a few weeks ago.
-
-A plain install of Debian GNU/Linux makes user processes catch
-spurious signals.  The kernel seems to run stably, though.
-
-The ADX feature works very poorly.  It might be related; at least it
-allows for reproducibly provoking invalid behaviour.
-
-Here is a test case:
-
-================================================================
-qemumain.c
-#include <stdio.h>
-long adx();
-int
-main ()
-{
-  printf ("%lx\n", adx (0xffbeef, 17));
-  return 0;
-}
-================================================================
-qemuadx.s:
-        .globl  adx
-adx:    xor     %rax, %rax
-1:      dec     %rdi
-        jnz     1b
-        .byte 0xf3, 0x48, 0x0f, 0x38, 0xf6, 0xc0        # adox  %rax, %rax
-        .byte 0x66, 0x48, 0x0f, 0x38, 0xf6, 0xc0        # adcx  %rax, %rax
-        ret
-================================================================
-
-Compile and execute:
-$ gcc -m64 qemumain.c qemuadx.s
-$ a.out
-ffffff8000378cd8
-
-Expected output is simply "0".  The garbage value varies between qemu
-compiles and guest systems.
-
-Note that one needs a recent GNU assembler in order to handle adox and
-adcx.  For convenience I have supplied them as byte sequences.
-
-Exaplanation and feeble analysis:
-
-The 0xffbeef argument is a loop count.  It is necessary to loop for a
-while in order to trigger this bug.  If the loop count is decreased,
-the bug will seen intermittently; the lower the count, the less
-frequent the invalid behaviour.
-
-It seems like a reasonable assumption that this bug is related to
-flags handling at context switch.  Presumably, qemu keeps flags state
-in some internal format, then recomputes then when needing to form the
-eflags register, as needed for example for context switching.
-
-I haven't tried to reproduce this bug using qemu-x86_64 and SYSROOT,
-but I strongly suspect that to be impossible.  I use
-qemu-system-x86_64 and the guest Debian GNU/Linux x86_64 (version
-6.0.6) .
-
-The bug happens also with the guest FreeBSD x86_64 version 9.1.  (The
-iteration count for triggering the problem 50% of the runs is not the
-same when using the kernel Linux and FreeBSD's kernel, presumably due
-to different ticks.)
-
-The bug happens much more frequently for a loaded system; in fact, the
-loop count can be radically decreased if two instances of the trigger
-program are run in parallel.
-
-Richard Henderson <email address hidden> writes:
-
-  Patch at http://patchwork.ozlabs.org/patch/229139/
-  
-Thanks.  I can confirm that this fixes the bug triggered by my test case
-(and yours).  However, the instability of Debian GNU/Linux x86_64 has
-not improved.
-
-The exact same Debian version (debian "testing") updated at the same
-time runs well on hardware.
-
-My qemu Debian system now got messed up, since I attempted an upgrade in
-the buggy qemu, which segfaulted several times during the upgrade.  I
-need to reinstall, and then rely on -snapshot.
-
-There is a problem with denorms which is reproducible, but whether that
-is a qemu bug, and whether it can actually cause the observed
-instability, is questionable.  Here is a testcase for that problem:
-
-
-
-
-It should terminate.  The observed buggy behaviour is that it hangs.
-
-The instability problem can be observed at gmplib.org/devel/tm-date.html.
-hwl-deb.gmplib.org is Debian under qemu with -cpu Haswell,+adx.
-
-Not that the exact same qemu runs FreeBSD flawlessly (hwl.gmplib.org).
-It is neither instable nor does it run the denorms testcase poorly.
-
-I fully realise this is a hopeless bug report, but I am sure you can
-reproduce it, since it is far from GMP specific.  After all apt-get
-update; apt-get upgrade triggered it.  Debugging it will be a nightmare.
-
-Qemu version: main git repo from less than a week ago + Richard ADX
-patch.
-
--- 
-Torbjörn
-
-
-It looks from this bug that we fixed the initial ADOX bug in commit c53de1a2896cc (2013), and I've just tried the 'qemu-denorm-problem.s' test case from comment #1 and it works OK, so I think we've fixed that denormals bug too. Given that, and that this bug report is 4 years old, I'm going to close it. If you're still having problems with recent versions of QEMU, please open a new bug.
-
-
diff --git a/results/classifier/016/assembly-x86/gitlab_semantic_addsubps b/results/classifier/016/assembly-x86/gitlab_semantic_addsubps
deleted file mode 100644
index 4aba98a8..00000000
--- a/results/classifier/016/assembly-x86/gitlab_semantic_addsubps
+++ /dev/null
@@ -1,55 +0,0 @@
-x86: 1.000
-assembly: 0.992
-semantic: 0.981
-i386: 0.817
-debug: 0.106
-register: 0.039
-files: 0.031
-user-level: 0.025
-risc-v: 0.019
-virtual: 0.016
-PID: 0.014
-TCG: 0.013
-VMM: 0.010
-performance: 0.010
-kernel: 0.008
-architecture: 0.008
-operating system: 0.007
-alpha: 0.006
-network: 0.006
-device: 0.004
-permissions: 0.004
-boot: 0.004
-hypervisor: 0.003
-socket: 0.003
-peripherals: 0.003
-vnc: 0.002
-graphic: 0.002
-KVM: 0.002
-ppc: 0.001
-mistranslation: 0.001
-arm: 0.000
-
-x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN
-
-Description of problem
-The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different.
-
-Steps to reproduce
-
-Compile this code
-
-void main() {
-    asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];");
-    asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];");
-    asm("addsubps xmm1, xmm2");
-}
-
-Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2.
-
-CPU xmm1[3] = 0xffffffff
-
-QEMU xmm1[3] = 0x7fffffff
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/016/assembly-x86/gitlab_semantic_adox b/results/classifier/016/assembly-x86/gitlab_semantic_adox
deleted file mode 100644
index 172b6260..00000000
--- a/results/classifier/016/assembly-x86/gitlab_semantic_adox
+++ /dev/null
@@ -1,68 +0,0 @@
-x86: 1.000
-assembly: 0.986
-semantic: 0.984
-i386: 0.965
-debug: 0.322
-register: 0.126
-operating system: 0.048
-files: 0.023
-TCG: 0.018
-kernel: 0.015
-performance: 0.015
-virtual: 0.013
-user-level: 0.009
-architecture: 0.007
-PID: 0.007
-device: 0.005
-peripherals: 0.005
-hypervisor: 0.004
-VMM: 0.004
-KVM: 0.003
-network: 0.002
-boot: 0.002
-graphic: 0.002
-permissions: 0.002
-socket: 0.002
-alpha: 0.002
-risc-v: 0.002
-ppc: 0.001
-vnc: 0.001
-mistranslation: 0.000
-arm: 0.000
-
-x86 ADOX and ADCX semantic bug
-Description of problem
-The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different.
-
-Steps to reproduce
-
-Compile this code
-
-
-void main() {
-    asm("push 512; popfq;");
-    asm("mov rax, 0xffffffff84fdbf24");
-    asm("mov rbx, 0xb197d26043bec15d");
-    asm("adox eax, ebx");
-}
-
-
-
-Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF).
-
-CPU
-
-OF = 0
-
-
-QEMU
-
-OF = 1
-
-
-
-
-
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/016/assembly-x86/gitlab_semantic_bextr b/results/classifier/016/assembly-x86/gitlab_semantic_bextr
deleted file mode 100644
index 3d1539ef..00000000
--- a/results/classifier/016/assembly-x86/gitlab_semantic_bextr
+++ /dev/null
@@ -1,57 +0,0 @@
-x86: 1.000
-assembly: 0.991
-semantic: 0.982
-i386: 0.980
-debug: 0.687
-register: 0.219
-user-level: 0.151
-operating system: 0.067
-virtual: 0.044
-files: 0.029
-kernel: 0.023
-hypervisor: 0.017
-performance: 0.017
-TCG: 0.016
-architecture: 0.009
-PID: 0.008
-peripherals: 0.007
-device: 0.007
-network: 0.006
-alpha: 0.003
-risc-v: 0.003
-VMM: 0.003
-permissions: 0.002
-socket: 0.002
-KVM: 0.002
-graphic: 0.002
-boot: 0.002
-ppc: 0.001
-vnc: 0.001
-mistranslation: 0.001
-arm: 0.000
-
-x86 BEXTR semantic bug
-Description of problem
-The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit.
-
-Steps to reproduce
-
-Compile this code
-
-void main() {
-    asm("mov rax, 0x17b3693f77fb6e9");
-    asm("mov rbx, 0x8f635a775ad3b9b4");
-    asm("mov rcx, 0xb717b75da9983018");
-    asm("bextr eax, ebx, ecx");
-}
-
-Execute and compare the result with the CPU.
-
-CPU
-RAX = 0x5a
-
-QEMU
-RAX = 0x635a775a
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/016/assembly-x86/gitlab_semantic_blsi b/results/classifier/016/assembly-x86/gitlab_semantic_blsi
deleted file mode 100644
index 002bc4ec..00000000
--- a/results/classifier/016/assembly-x86/gitlab_semantic_blsi
+++ /dev/null
@@ -1,52 +0,0 @@
-x86: 1.000
-assembly: 0.985
-semantic: 0.981
-i386: 0.962
-debug: 0.206
-register: 0.172
-operating system: 0.060
-performance: 0.033
-kernel: 0.027
-files: 0.026
-TCG: 0.018
-architecture: 0.012
-virtual: 0.011
-user-level: 0.010
-PID: 0.009
-peripherals: 0.007
-device: 0.006
-risc-v: 0.005
-VMM: 0.005
-alpha: 0.005
-hypervisor: 0.004
-network: 0.004
-permissions: 0.003
-boot: 0.003
-KVM: 0.003
-graphic: 0.003
-socket: 0.002
-vnc: 0.001
-mistranslation: 0.001
-ppc: 0.000
-arm: 0.000
-
-x86 BLSI and BLSR semantic bug
-Description of problem
-The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different.
-
-Steps to reproduce
-
-Compile this code
-
-
-void main() {
-    asm("blsi rax, rbx");
-}
-
-
-
-Execute and compare the result with the CPU. The value of CF is exactly the opposite. This problem happens with BLSR, too.
-
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/016/assembly-x86/gitlab_semantic_bzhi b/results/classifier/016/assembly-x86/gitlab_semantic_bzhi
deleted file mode 100644
index fc53b1ca..00000000
--- a/results/classifier/016/assembly-x86/gitlab_semantic_bzhi
+++ /dev/null
@@ -1,70 +0,0 @@
-x86: 1.000
-i386: 0.989
-assembly: 0.989
-semantic: 0.987
-debug: 0.282
-register: 0.159
-operating system: 0.067
-kernel: 0.025
-files: 0.022
-TCG: 0.021
-performance: 0.021
-virtual: 0.020
-user-level: 0.013
-hypervisor: 0.010
-architecture: 0.009
-PID: 0.008
-device: 0.008
-peripherals: 0.007
-KVM: 0.004
-network: 0.004
-VMM: 0.003
-risc-v: 0.003
-socket: 0.003
-permissions: 0.003
-boot: 0.003
-alpha: 0.002
-graphic: 0.002
-vnc: 0.001
-ppc: 0.001
-mistranslation: 0.001
-arm: 0.000
-
-x86 BZHI semantic bug
-Description of problem
-The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different.
-
-Steps to reproduce
-
-Compile this code
-
-
-void main() {
-    asm("mov rax, 0xb1aa9da2fe33fe3");
-    asm("mov rbx, 0x80000000ffffffff");
-    asm("mov rcx, 0xf3fce8829b99a5c6");
-    asm("bzhi rax, rbx, rcx");
-}
-
-
-
-Execute and compare the result with the CPU.
-
-CPU
-
-RAX = 0x0x80000000ffffffff
-SF = 1
-
-
-QEMU
-
-RAX = 0xffffffff
-SF = 0
-
-
-
-
-
-
-Additional information
-This bug is discovered by research conducted by KAIST SoftSec.