2 files changed, 0 insertions, 97 deletions
diff --git a/results/classifier/semantic-bugs/instruction/1771 b/results/classifier/semantic-bugs/instruction/1771
deleted file mode 100644
index 3195f46f5..000000000
--- a/results/classifier/semantic-bugs/instruction/1771
+++ /dev/null
@@ -1,46 +0,0 @@
-instruction: 0.977
-graphic: 0.917
-device: 0.843
-socket: 0.778
-semantic: 0.749
-vnc: 0.729
-network: 0.581
-boot: 0.572
-other: 0.534
-mistranslation: 0.523
-assembly: 0.491
-KVM: 0.118
-
-Missing CASA instruction handling for SPARC qemu-user
-Description of problem:
-Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it.
-Steps to reproduce:
-1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31])
-2. qemu-sparc will raise "Illegal instruction"
-Additional information:
-The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space.
-
-```
-diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c
---- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200
-+++ qemu-20230327/target/sparc/translate.c      2023-04-01 15:24:18.293176711 +0200
-@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex
-                 case 0x37: /* stdc */
-                     goto ncp_insn;
- #endif
--#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
-+//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
-                 case 0x3c: /* V9 or LEON3 casa */
- #ifndef TARGET_SPARC64
-                     CHECK_IU_FEATURE(dc, CASA);
-@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex
-                     rs2 = GET_FIELD(insn, 27, 31);
-                     cpu_src2 = gen_load_gpr(dc, rs2);
-                     gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd);
-+//#endif
-                     break;
--#endif
-                 default:
-                     goto illegal_insn;
-                 }
-```
diff --git a/results/classifier/semantic-bugs/instruction/1771948 b/results/classifier/semantic-bugs/instruction/1771948
deleted file mode 100644
index 636db688b..000000000
--- a/results/classifier/semantic-bugs/instruction/1771948
+++ /dev/null
@@ -1,51 +0,0 @@
-instruction: 0.898
-other: 0.852
-graphic: 0.837
-semantic: 0.818
-device: 0.763
-network: 0.610
-vnc: 0.606
-socket: 0.601
-mistranslation: 0.540
-assembly: 0.504
-boot: 0.482
-KVM: 0.408
-
-aarch64 msr CNTFRQ_EL0
-
-Hello,
-
-I'm running qemu 2.12 on a raspberry pi 3 with the command:
-
-qemu-system-aarch64 -M raspi3 -serial stdio -kernel executable.bin
-
-On my start file (right in the beginning with the highest EL), the following instructions:
-
-ldr x0 , =19200000
-msr CNTFRQ_EL0, x0
-
-
-and qemu halts on the "msr CNTFRQ_EL0, x0" instruction.
-
-I believe this is not a normal behavior.
-
-Thank you
-
-Mmm, that's not really supposed to happen. Do you have a test guest binary you can attach that I can reproduce with?
-
-
-Looking more closely at this, I think this is because you've passed QEMU a file which it is treating as a Linux kernel. (-kernel treats raw binaries and uimage files as Linux kernels; it treats ELF files as not being Linux kernels). Linux expects to be started in EL2, so although the emulated CPU has EL3, we start your program in EL2. Your program is therefore not running at the highest available exception level, and can't write to CNTFRQ_EL0.
-
-For "bare metal" images where you want to do things at EL3, it may be better to build them as ELF files which are linked to load at address 0. Note that all four cores will start at address zero simultaneously, so you'll need a bit of "pen code" to sort the secondaries out from the primary. https://github.com/raspberrypi/tools/blob/master/armstubs/armstub8.S might be useful reference. As I understand it, this is how your code would be run on real raspi3 hardware too.
-
-
-Thank you for your reply. Sorry to take so long (was on vacations).
-
-Your comment seems correct to me. I tried with the ELF file instead of the binary file and it worked perfectly (and all the cores were running instead of just core 0).
-
-From my point of view, this bug can be marked as invalid.
-
-Thank you again.
-
-
-