add deepseek and gemma results

1 files changed, 0 insertions, 25 deletions

diff --git a/results/classifier/deepseek-2-tmp/output/hypervisor/1072 b/results/classifier/deepseek-2-tmp/output/hypervisor/1072
deleted file mode 100644
index 0181b249b..000000000
--- a/results/classifier/deepseek-2-tmp/output/hypervisor/1072
+++ /dev/null
@@ -1,25 +0,0 @@
-
-different behavior when remote debugger is used
-Description of problem:
-I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: 
-
-1. Is this intended behavior?
-1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below)
-1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference.
-
-The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR)
-The preprocessed code is as follows:
-   if (((((st.st_mode)) & 0170000) == (0020000))) 
-
-I then compared two different approaches to run Qemu:
-
-1. I used the following command line to collect the trace:  qemu_aarch64 -strace  -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR
-1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). 
-
-Thanks!
-Steps to reproduce:
-1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64)
-2.
-3.
-Additional information:
-