94 files changed, 0 insertions, 1381 deletions
diff --git a/results/classifier/semantic-bugs/instruction/1079080 b/results/classifier/semantic-bugs/1079080
index c3723248d..c3723248d 100644
--- a/results/classifier/semantic-bugs/instruction/1079080
+++ b/results/classifier/semantic-bugs/1079080
diff --git a/results/classifier/semantic-bugs/instruction/1092 b/results/classifier/semantic-bugs/1092
index 544940be7..544940be7 100644
--- a/results/classifier/semantic-bugs/instruction/1092
+++ b/results/classifier/semantic-bugs/1092
diff --git a/results/classifier/semantic-bugs/instruction/1095857 b/results/classifier/semantic-bugs/1095857
index a74648b9b..a74648b9b 100644
--- a/results/classifier/semantic-bugs/instruction/1095857
+++ b/results/classifier/semantic-bugs/1095857
diff --git a/results/classifier/semantic-bugs/instruction/1156 b/results/classifier/semantic-bugs/1156
index 83908c6d9..83908c6d9 100644
--- a/results/classifier/semantic-bugs/instruction/1156
+++ b/results/classifier/semantic-bugs/1156
diff --git a/results/classifier/semantic-bugs/semantic/1156313 b/results/classifier/semantic-bugs/1156313
index 54d2d0f95..54d2d0f95 100644
--- a/results/classifier/semantic-bugs/semantic/1156313
+++ b/results/classifier/semantic-bugs/1156313
diff --git a/results/classifier/semantic-bugs/instruction/1245543 b/results/classifier/semantic-bugs/1245543
index 99966ab81..99966ab81 100644
--- a/results/classifier/semantic-bugs/instruction/1245543
+++ b/results/classifier/semantic-bugs/1245543
diff --git a/results/classifier/semantic-bugs/instruction/1248168 b/results/classifier/semantic-bugs/1248168
index 22e04de30..22e04de30 100644
--- a/results/classifier/semantic-bugs/instruction/1248168
+++ b/results/classifier/semantic-bugs/1248168
diff --git a/results/classifier/semantic-bugs/other/1267955 b/results/classifier/semantic-bugs/1267955
index fe1635901..fe1635901 100644
--- a/results/classifier/semantic-bugs/other/1267955
+++ b/results/classifier/semantic-bugs/1267955
diff --git a/results/classifier/semantic-bugs/instruction/1328996 b/results/classifier/semantic-bugs/1328996
index b48ededc8..b48ededc8 100644
--- a/results/classifier/semantic-bugs/instruction/1328996
+++ b/results/classifier/semantic-bugs/1328996
diff --git a/results/classifier/semantic-bugs/semantic/1370 b/results/classifier/semantic-bugs/1370
index c7f125abf..c7f125abf 100644
--- a/results/classifier/semantic-bugs/semantic/1370
+++ b/results/classifier/semantic-bugs/1370
diff --git a/results/classifier/semantic-bugs/semantic/1371 b/results/classifier/semantic-bugs/1371
index 16aca0c8f..16aca0c8f 100644
--- a/results/classifier/semantic-bugs/semantic/1371
+++ b/results/classifier/semantic-bugs/1371
diff --git a/results/classifier/semantic-bugs/semantic/1372 b/results/classifier/semantic-bugs/1372
index a5a86bb81..a5a86bb81 100644
--- a/results/classifier/semantic-bugs/semantic/1372
+++ b/results/classifier/semantic-bugs/1372
diff --git a/results/classifier/semantic-bugs/semantic/1373 b/results/classifier/semantic-bugs/1373
index d4cf2ba67..d4cf2ba67 100644
--- a/results/classifier/semantic-bugs/semantic/1373
+++ b/results/classifier/semantic-bugs/1373
diff --git a/results/classifier/semantic-bugs/semantic/1374 b/results/classifier/semantic-bugs/1374
index 0db6a0198..0db6a0198 100644
--- a/results/classifier/semantic-bugs/semantic/1374
+++ b/results/classifier/semantic-bugs/1374
diff --git a/results/classifier/semantic-bugs/semantic/1375 b/results/classifier/semantic-bugs/1375
index 3d7746382..3d7746382 100644
--- a/results/classifier/semantic-bugs/semantic/1375
+++ b/results/classifier/semantic-bugs/1375
diff --git a/results/classifier/semantic-bugs/instruction/1376 b/results/classifier/semantic-bugs/1376
index 3f75ca7c9..3f75ca7c9 100644
--- a/results/classifier/semantic-bugs/instruction/1376
+++ b/results/classifier/semantic-bugs/1376
diff --git a/results/classifier/semantic-bugs/instruction/1377 b/results/classifier/semantic-bugs/1377
index f3d87d4fe..f3d87d4fe 100644
--- a/results/classifier/semantic-bugs/instruction/1377
+++ b/results/classifier/semantic-bugs/1377
diff --git a/results/classifier/semantic-bugs/instruction/1574346 b/results/classifier/semantic-bugs/1574346
index 410bb5bab..410bb5bab 100644
--- a/results/classifier/semantic-bugs/instruction/1574346
+++ b/results/classifier/semantic-bugs/1574346
diff --git a/results/classifier/semantic-bugs/assembly/1612 b/results/classifier/semantic-bugs/1612
index aa2f4e529..aa2f4e529 100644
--- a/results/classifier/semantic-bugs/assembly/1612
+++ b/results/classifier/semantic-bugs/1612
diff --git a/results/classifier/semantic-bugs/assembly/1620 b/results/classifier/semantic-bugs/1620
index ecfad33cc..ecfad33cc 100644
--- a/results/classifier/semantic-bugs/assembly/1620
+++ b/results/classifier/semantic-bugs/1620
diff --git a/results/classifier/semantic-bugs/instruction/1637 b/results/classifier/semantic-bugs/1637
index 9656c06fd..9656c06fd 100644
--- a/results/classifier/semantic-bugs/instruction/1637
+++ b/results/classifier/semantic-bugs/1637
diff --git a/results/classifier/semantic-bugs/graphic/1641637 b/results/classifier/semantic-bugs/1641637
index dff815184..dff815184 100644
--- a/results/classifier/semantic-bugs/graphic/1641637
+++ b/results/classifier/semantic-bugs/1641637
diff --git a/results/classifier/semantic-bugs/graphic/1722 b/results/classifier/semantic-bugs/1722
index 4dcbfc5fe..4dcbfc5fe 100644
--- a/results/classifier/semantic-bugs/graphic/1722
+++ b/results/classifier/semantic-bugs/1722
diff --git a/results/classifier/semantic-bugs/instruction/1737 b/results/classifier/semantic-bugs/1737
index 3b07da097..3b07da097 100644
--- a/results/classifier/semantic-bugs/instruction/1737
+++ b/results/classifier/semantic-bugs/1737
diff --git a/results/classifier/semantic-bugs/instruction/1738434 b/results/classifier/semantic-bugs/1738434
index e6167f2d3..e6167f2d3 100644
--- a/results/classifier/semantic-bugs/instruction/1738434
+++ b/results/classifier/semantic-bugs/1738434
diff --git a/results/classifier/semantic-bugs/boot/1748296 b/results/classifier/semantic-bugs/1748296
index cab7dadc5..cab7dadc5 100644
--- a/results/classifier/semantic-bugs/boot/1748296
+++ b/results/classifier/semantic-bugs/1748296
diff --git a/results/classifier/semantic-bugs/instruction/1751422 b/results/classifier/semantic-bugs/1751422
index df415ac99..df415ac99 100644
--- a/results/classifier/semantic-bugs/instruction/1751422
+++ b/results/classifier/semantic-bugs/1751422
diff --git a/results/classifier/semantic-bugs/instruction/1751494 b/results/classifier/semantic-bugs/1751494
index 2e2e48a44..2e2e48a44 100644
--- a/results/classifier/semantic-bugs/instruction/1751494
+++ b/results/classifier/semantic-bugs/1751494
diff --git a/results/classifier/semantic-bugs/instruction/1756927 b/results/classifier/semantic-bugs/1756927
index 3ec2692ab..3ec2692ab 100644
--- a/results/classifier/semantic-bugs/instruction/1756927
+++ b/results/classifier/semantic-bugs/1756927
diff --git a/results/classifier/semantic-bugs/instruction/1771 b/results/classifier/semantic-bugs/1771
index 3195f46f5..3195f46f5 100644
--- a/results/classifier/semantic-bugs/instruction/1771
+++ b/results/classifier/semantic-bugs/1771
diff --git a/results/classifier/semantic-bugs/instruction/1780 b/results/classifier/semantic-bugs/1780
index 354a178d0..354a178d0 100644
--- a/results/classifier/semantic-bugs/instruction/1780
+++ b/results/classifier/semantic-bugs/1780
diff --git a/results/classifier/semantic-bugs/vnc/1785734 b/results/classifier/semantic-bugs/1785734
index 127f85c5e..127f85c5e 100644
--- a/results/classifier/semantic-bugs/vnc/1785734
+++ b/results/classifier/semantic-bugs/1785734
diff --git a/results/classifier/semantic-bugs/instruction/1790 b/results/classifier/semantic-bugs/1790
index 2a0a409bf..2a0a409bf 100644
--- a/results/classifier/semantic-bugs/instruction/1790
+++ b/results/classifier/semantic-bugs/1790
diff --git a/results/classifier/semantic-bugs/instruction/1793608 b/results/classifier/semantic-bugs/1793608
index b6a6faa1b..b6a6faa1b 100644
--- a/results/classifier/semantic-bugs/instruction/1793608
+++ b/results/classifier/semantic-bugs/1793608
diff --git a/results/classifier/semantic-bugs/semantic/1809546 b/results/classifier/semantic-bugs/1809546
index dfeb2f575..dfeb2f575 100644
--- a/results/classifier/semantic-bugs/semantic/1809546
+++ b/results/classifier/semantic-bugs/1809546
diff --git a/results/classifier/semantic-bugs/instruction/1818075 b/results/classifier/semantic-bugs/1818075
index 26b345c17..26b345c17 100644
--- a/results/classifier/semantic-bugs/instruction/1818075
+++ b/results/classifier/semantic-bugs/1818075
diff --git a/results/classifier/semantic-bugs/instruction/1820686 b/results/classifier/semantic-bugs/1820686
index f7fd19f6d..f7fd19f6d 100644
--- a/results/classifier/semantic-bugs/instruction/1820686
+++ b/results/classifier/semantic-bugs/1820686
diff --git a/results/classifier/semantic-bugs/instruction/1824344 b/results/classifier/semantic-bugs/1824344
index 9886d36a4..9886d36a4 100644
--- a/results/classifier/semantic-bugs/instruction/1824344
+++ b/results/classifier/semantic-bugs/1824344
diff --git a/results/classifier/semantic-bugs/instruction/1824778 b/results/classifier/semantic-bugs/1824778
index d9e3e95db..d9e3e95db 100644
--- a/results/classifier/semantic-bugs/instruction/1824778
+++ b/results/classifier/semantic-bugs/1824778
diff --git a/results/classifier/semantic-bugs/instruction/1828867 b/results/classifier/semantic-bugs/1828867
index 05260e5d1..05260e5d1 100644
--- a/results/classifier/semantic-bugs/instruction/1828867
+++ b/results/classifier/semantic-bugs/1828867
diff --git a/results/classifier/semantic-bugs/instruction/1832422 b/results/classifier/semantic-bugs/1832422
index 39c39a63d..39c39a63d 100644
--- a/results/classifier/semantic-bugs/instruction/1832422
+++ b/results/classifier/semantic-bugs/1832422
diff --git a/results/classifier/semantic-bugs/mistranslation/1861404 b/results/classifier/semantic-bugs/1861404
index f905e83ae..f905e83ae 100644
--- a/results/classifier/semantic-bugs/mistranslation/1861404
+++ b/results/classifier/semantic-bugs/1861404
diff --git a/results/classifier/semantic-bugs/instruction/1863247 b/results/classifier/semantic-bugs/1863247
index 072da78e3..072da78e3 100644
--- a/results/classifier/semantic-bugs/instruction/1863247
+++ b/results/classifier/semantic-bugs/1863247
diff --git a/results/classifier/semantic-bugs/instruction/1898954 b/results/classifier/semantic-bugs/1898954
index 77df51de8..77df51de8 100644
--- a/results/classifier/semantic-bugs/instruction/1898954
+++ b/results/classifier/semantic-bugs/1898954
diff --git a/results/classifier/semantic-bugs/instruction/1901 b/results/classifier/semantic-bugs/1901
index 33ec55668..33ec55668 100644
--- a/results/classifier/semantic-bugs/instruction/1901
+++ b/results/classifier/semantic-bugs/1901
diff --git a/results/classifier/semantic-bugs/instruction/1912934 b/results/classifier/semantic-bugs/1912934
index f487e30df..f487e30df 100644
--- a/results/classifier/semantic-bugs/instruction/1912934
+++ b/results/classifier/semantic-bugs/1912934
diff --git a/results/classifier/semantic-bugs/instruction/1916269 b/results/classifier/semantic-bugs/1916269
index 45a2ef615..45a2ef615 100644
--- a/results/classifier/semantic-bugs/instruction/1916269
+++ b/results/classifier/semantic-bugs/1916269
diff --git a/results/classifier/semantic-bugs/instruction/1926759 b/results/classifier/semantic-bugs/1926759
index 753b9e4d4..753b9e4d4 100644
--- a/results/classifier/semantic-bugs/instruction/1926759
+++ b/results/classifier/semantic-bugs/1926759
diff --git a/results/classifier/semantic-bugs/instruction/1955 b/results/classifier/semantic-bugs/1955
index 17cd3a9de..17cd3a9de 100644
--- a/results/classifier/semantic-bugs/instruction/1955
+++ b/results/classifier/semantic-bugs/1955
diff --git a/results/classifier/semantic-bugs/instruction/2089 b/results/classifier/semantic-bugs/2089
index 4241b84e5..4241b84e5 100644
--- a/results/classifier/semantic-bugs/instruction/2089
+++ b/results/classifier/semantic-bugs/2089
diff --git a/results/classifier/semantic-bugs/instruction/2175 b/results/classifier/semantic-bugs/2175
index 874c3bcde..874c3bcde 100644
--- a/results/classifier/semantic-bugs/instruction/2175
+++ b/results/classifier/semantic-bugs/2175
diff --git a/results/classifier/semantic-bugs/instruction/2248 b/results/classifier/semantic-bugs/2248
index ae3a6196e..ae3a6196e 100644
--- a/results/classifier/semantic-bugs/instruction/2248
+++ b/results/classifier/semantic-bugs/2248
diff --git a/results/classifier/semantic-bugs/instruction/2302 b/results/classifier/semantic-bugs/2302
index dd607123b..dd607123b 100644
--- a/results/classifier/semantic-bugs/instruction/2302
+++ b/results/classifier/semantic-bugs/2302
diff --git a/results/classifier/semantic-bugs/instruction/2317 b/results/classifier/semantic-bugs/2317
index 0acfd4575..0acfd4575 100644
--- a/results/classifier/semantic-bugs/instruction/2317
+++ b/results/classifier/semantic-bugs/2317
diff --git a/results/classifier/semantic-bugs/instruction/2318 b/results/classifier/semantic-bugs/2318
index 3defce0d6..3defce0d6 100644
--- a/results/classifier/semantic-bugs/instruction/2318
+++ b/results/classifier/semantic-bugs/2318
diff --git a/results/classifier/semantic-bugs/other/2371 b/results/classifier/semantic-bugs/2371
index 2db65ca18..2db65ca18 100644
--- a/results/classifier/semantic-bugs/other/2371
+++ b/results/classifier/semantic-bugs/2371
diff --git a/results/classifier/semantic-bugs/other/2372 b/results/classifier/semantic-bugs/2372
index 577fd84ae..577fd84ae 100644
--- a/results/classifier/semantic-bugs/other/2372
+++ b/results/classifier/semantic-bugs/2372
diff --git a/results/classifier/semantic-bugs/other/2374 b/results/classifier/semantic-bugs/2374
index 676db53f4..676db53f4 100644
--- a/results/classifier/semantic-bugs/other/2374
+++ b/results/classifier/semantic-bugs/2374
diff --git a/results/classifier/semantic-bugs/instruction/2386 b/results/classifier/semantic-bugs/2386
index 96e88af3c..96e88af3c 100644
--- a/results/classifier/semantic-bugs/instruction/2386
+++ b/results/classifier/semantic-bugs/2386
diff --git a/results/classifier/semantic-bugs/instruction/2497 b/results/classifier/semantic-bugs/2497
index ccc110c51..ccc110c51 100644
--- a/results/classifier/semantic-bugs/instruction/2497
+++ b/results/classifier/semantic-bugs/2497
diff --git a/results/classifier/semantic-bugs/instruction/2500 b/results/classifier/semantic-bugs/2500
index 4939d31cc..4939d31cc 100644
--- a/results/classifier/semantic-bugs/instruction/2500
+++ b/results/classifier/semantic-bugs/2500
diff --git a/results/classifier/semantic-bugs/graphic/2595 b/results/classifier/semantic-bugs/2595
index e0e1afbe0..e0e1afbe0 100644
--- a/results/classifier/semantic-bugs/graphic/2595
+++ b/results/classifier/semantic-bugs/2595
diff --git a/results/classifier/semantic-bugs/mistranslation/266 b/results/classifier/semantic-bugs/266
index 4824b4c1d..4824b4c1d 100644
--- a/results/classifier/semantic-bugs/mistranslation/266
+++ b/results/classifier/semantic-bugs/266
diff --git a/results/classifier/semantic-bugs/graphic/2672 b/results/classifier/semantic-bugs/2672
index 3a1f3f9a5..3a1f3f9a5 100644
--- a/results/classifier/semantic-bugs/graphic/2672
+++ b/results/classifier/semantic-bugs/2672
diff --git a/results/classifier/semantic-bugs/instruction/2865 b/results/classifier/semantic-bugs/2865
index 993bac92e..993bac92e 100644
--- a/results/classifier/semantic-bugs/instruction/2865
+++ b/results/classifier/semantic-bugs/2865
diff --git a/results/classifier/semantic-bugs/instruction/2971 b/results/classifier/semantic-bugs/2971
index 2ee49f8b8..2ee49f8b8 100644
--- a/results/classifier/semantic-bugs/instruction/2971
+++ b/results/classifier/semantic-bugs/2971
diff --git a/results/classifier/semantic-bugs/instruction/361 b/results/classifier/semantic-bugs/361
index ee26ed4b0..ee26ed4b0 100644
--- a/results/classifier/semantic-bugs/instruction/361
+++ b/results/classifier/semantic-bugs/361
diff --git a/results/classifier/semantic-bugs/instruction/390 b/results/classifier/semantic-bugs/390
index 61671b821..61671b821 100644
--- a/results/classifier/semantic-bugs/instruction/390
+++ b/results/classifier/semantic-bugs/390
diff --git a/results/classifier/semantic-bugs/mistranslation/427 b/results/classifier/semantic-bugs/427
index c11b42a46..c11b42a46 100644
--- a/results/classifier/semantic-bugs/mistranslation/427
+++ b/results/classifier/semantic-bugs/427
diff --git a/results/classifier/semantic-bugs/mistranslation/508 b/results/classifier/semantic-bugs/508
index b05d57a9e..b05d57a9e 100644
--- a/results/classifier/semantic-bugs/mistranslation/508
+++ b/results/classifier/semantic-bugs/508
diff --git a/results/classifier/semantic-bugs/instruction/514 b/results/classifier/semantic-bugs/514
index f973fe24b..f973fe24b 100644
--- a/results/classifier/semantic-bugs/instruction/514
+++ b/results/classifier/semantic-bugs/514
diff --git a/results/classifier/semantic-bugs/instruction/799 b/results/classifier/semantic-bugs/799
index b6de1812e..b6de1812e 100644
--- a/results/classifier/semantic-bugs/instruction/799
+++ b/results/classifier/semantic-bugs/799
diff --git a/results/classifier/semantic-bugs/instruction/824 b/results/classifier/semantic-bugs/824
index cf7795167..cf7795167 100644
--- a/results/classifier/semantic-bugs/instruction/824
+++ b/results/classifier/semantic-bugs/824
diff --git a/results/classifier/semantic-bugs/instruction/826 b/results/classifier/semantic-bugs/826
index 3ef3962e4..3ef3962e4 100644
--- a/results/classifier/semantic-bugs/instruction/826
+++ b/results/classifier/semantic-bugs/826
diff --git a/results/classifier/semantic-bugs/graphic/904308 b/results/classifier/semantic-bugs/904308
index a32657642..a32657642 100644
--- a/results/classifier/semantic-bugs/graphic/904308
+++ b/results/classifier/semantic-bugs/904308
diff --git a/results/classifier/semantic-bugs/instruction/984 b/results/classifier/semantic-bugs/984
index 0458e2758..0458e2758 100644
--- a/results/classifier/semantic-bugs/instruction/984
+++ b/results/classifier/semantic-bugs/984
diff --git a/results/classifier/semantic-bugs/assembly/1649 b/results/classifier/semantic-bugs/assembly/1649
deleted file mode 100644
index 7d78cca98..000000000
--- a/results/classifier/semantic-bugs/assembly/1649
+++ /dev/null
@@ -1,30 +0,0 @@
-assembly: 0.984
-instruction: 0.900
-graphic: 0.900
-device: 0.747
-semantic: 0.642
-vnc: 0.610
-network: 0.592
-socket: 0.542
-mistranslation: 0.500
-boot: 0.379
-KVM: 0.352
-other: 0.209
-
-"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register
-Description of problem:
-slli a0, a0, 8 (1)
-    la a0, mtimvec (2)
-    csrw mtvec, a0 (3)
-    mtimvec:       (4)
-
-For the above assembly snippet, the mtvec could be successfully set to the value of a0 
-without the presence of the line (1) or with the shift amount being zero. However, 
-the mtvec can never be set successfully with the presence of line (1).
-Steps to reproduce:
-1. Create a test.s file and put these 4 lines of assembly into the file
-2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S"
-3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0.
-4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value.
-Additional information:
-
diff --git a/results/classifier/semantic-bugs/assembly/904 b/results/classifier/semantic-bugs/assembly/904
deleted file mode 100644
index 4946b8146..000000000
--- a/results/classifier/semantic-bugs/assembly/904
+++ /dev/null
@@ -1,29 +0,0 @@
-assembly: 0.991
-instruction: 0.939
-graphic: 0.875
-device: 0.846
-semantic: 0.662
-network: 0.599
-mistranslation: 0.507
-vnc: 0.485
-boot: 0.425
-socket: 0.381
-KVM: 0.219
-other: 0.191
-
-RISC-V: Cannot set SEIP bit of mip csr register in M mode
-Description of problem:
-
-Steps to reproduce:
-1.   run assembly instructions **in M mode**: 
-```
-not t0, x0    // set t0 to 0b11..11
-csrs mip, t0  // write mip with t0, mip registers are WARL(Write Any Values, Reads Legal Values)
-csrr t1, mip  // read value from mip to t1
-```
-2.   GDB enters the command `display/z $t1` to see that the content of the t1 register is 0x466, which means that the SEIP bit of mip is not set.
-3.   According to page 47 of [riscv-privileged-20211203](https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf), `SEIP is writable in mip`.
-4.   According to page 81 of the same manual,`If implemented, SEIP is read-only in sip`.
-5.   However, the above code and results show that the SEIP bit of mip cannot be set by software **in M mode**.
-Additional information:
-
diff --git a/results/classifier/semantic-bugs/instruction/1057 b/results/classifier/semantic-bugs/instruction/1057
deleted file mode 100644
index 5815e3deb..000000000
--- a/results/classifier/semantic-bugs/instruction/1057
+++ /dev/null
@@ -1,36 +0,0 @@
-instruction: 0.938
-semantic: 0.521
-device: 0.491
-other: 0.379
-assembly: 0.282
-graphic: 0.233
-network: 0.207
-mistranslation: 0.133
-socket: 0.065
-KVM: 0.060
-vnc: 0.056
-boot: 0.050
-
-AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions
-Description of problem:
-I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction:
-`0x0000000000000000:  C3 44 00 B8    str   w3, [x6], #4`
-
-notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting.
-
-Here is the relevant part of the manual:
-
-```
-For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts:
-• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback).
-```
-
-However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions.
-
-Another example of instruction: `0x00000000000002f8:  01 1C 40 38    ldrb  w1, [x0, #1]!`
-Steps to reproduce:
-1. Run some hypervisor in EL2
-2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP)
-3. Observe the value of ESR_EL2 on data abort
-
-Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch.
diff --git a/results/classifier/semantic-bugs/instruction/1062 b/results/classifier/semantic-bugs/instruction/1062
deleted file mode 100644
index 67d2da1cb..000000000
--- a/results/classifier/semantic-bugs/instruction/1062
+++ /dev/null
@@ -1,29 +0,0 @@
-instruction: 0.925
-graphic: 0.906
-assembly: 0.851
-device: 0.826
-mistranslation: 0.798
-socket: 0.727
-network: 0.651
-semantic: 0.646
-vnc: 0.606
-other: 0.562
-boot: 0.478
-KVM: 0.082
-
-AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32
-Description of problem:
-In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support.
-
-This would break this EL3 code, which should run on cpu reset to attempt to return to EL1:
-```asm
-mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked
-mov SPSR_EL3, x1
-adr x1, 1f
-msr ELR_EL3, x1
-eret
-1:
-; something something
-```
-Additional information:
-
diff --git a/results/classifier/semantic-bugs/instruction/1204 b/results/classifier/semantic-bugs/instruction/1204
deleted file mode 100644
index e47ce874a..000000000
--- a/results/classifier/semantic-bugs/instruction/1204
+++ /dev/null
@@ -1,42 +0,0 @@
-instruction: 0.457
-device: 0.406
-graphic: 0.397
-semantic: 0.357
-network: 0.356
-socket: 0.345
-assembly: 0.330
-vnc: 0.306
-mistranslation: 0.284
-other: 0.165
-boot: 0.147
-KVM: 0.125
-
-AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0
-Description of problem:
-As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119).
-Memory regions marked as Device do not support unaligned access.
-Steps to reproduce:
-Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault)
-```
-.balign 8
-.global first_variable
-first_variable:
-      .word 0x1
-.balign 4
-.global second_variable
-second_variable:
-      .word 0x2
-
-no_mmu_sctlr: .dword 0x0000000030C51834
-
-.globl reproducer
-reproducer:
-      ldr  x1, no_mmu_sctlr // A=0,M=0
-      msr  sctlr_el3, x1
-      dsb  sy
-      isb
-
-      ldr  x0, =first_variable
-      ldr  x1, [x0, #0] // Aligned - Success
-      ldr  x1, [x0, #4] // Unaligned - Success??? (Should be failure)
-```
diff --git a/results/classifier/semantic-bugs/instruction/1498 b/results/classifier/semantic-bugs/instruction/1498
deleted file mode 100644
index 2ac4b50f4..000000000
--- a/results/classifier/semantic-bugs/instruction/1498
+++ /dev/null
@@ -1,18 +0,0 @@
-instruction: 0.978
-graphic: 0.914
-other: 0.851
-device: 0.849
-semantic: 0.841
-mistranslation: 0.800
-network: 0.564
-boot: 0.371
-vnc: 0.362
-socket: 0.166
-assembly: 0.098
-KVM: 0.027
-
-LDC, STC unimplemented in qemu-system-arm
-Description of problem:
-I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected.
-
-The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU.
diff --git a/results/classifier/semantic-bugs/instruction/1719984 b/results/classifier/semantic-bugs/instruction/1719984
deleted file mode 100644
index 909f6f0d9..000000000
--- a/results/classifier/semantic-bugs/instruction/1719984
+++ /dev/null
@@ -1,27 +0,0 @@
-instruction: 0.917
-graphic: 0.887
-mistranslation: 0.851
-device: 0.786
-network: 0.762
-semantic: 0.650
-boot: 0.624
-socket: 0.597
-vnc: 0.595
-KVM: 0.312
-other: 0.185
-assembly: 0.157
-
-wrgsbase misemulated in x86_64-softmmu
-
-qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4
-command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true '
-
-On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1.  In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference.
-
-For further data, the faulting instruction is
-f3 48 0f ae df          wrgsbase %rdi
-
-Fix is in staging: https://github.com/ehabkost/qemu/commit/cdcc80d41360e278b45c91de29a29d797264e85d
-
-Fix is in master: https://github.com/qemu/qemu/commit/e0dd5fd41a1a38766009f442967fab700d2d0550
-
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.
-
-
-
diff --git a/results/classifier/semantic-bugs/instruction/1889288 b/results/classifier/semantic-bugs/instruction/1889288
deleted file mode 100644
index 4b1ea1874..000000000
--- a/results/classifier/semantic-bugs/instruction/1889288
+++ /dev/null
@@ -1,26 +0,0 @@
-instruction: 0.757
-mistranslation: 0.724
-semantic: 0.599
-graphic: 0.519
-assembly: 0.467
-other: 0.455
-device: 0.440
-socket: 0.381
-vnc: 0.348
-network: 0.348
-boot: 0.182
-KVM: 0.137
-
-aarch64 BICS instruciton doesn't set flags
-
-When reading the source for translate-a64.c here:
-
-https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783
-
-I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug.
-
-The code is correct (though it is admittedly not entirely obvious at first glance). The switch statement at line 4753 is on "(opc | (invert << 2))" (where opc is a 2 bit field and invert a 1 bit field). Both ANDS and BICS have opc==3 and so will cause a call to gen_logic_CC(). The difference between the two insns is that ANDC has invert==0 and BICS has invert==1.
-
-
-Oh yes I see. Sorry for the false report.
-
diff --git a/results/classifier/semantic-bugs/instruction/1915027 b/results/classifier/semantic-bugs/instruction/1915027
deleted file mode 100644
index 4df7ceb4b..000000000
--- a/results/classifier/semantic-bugs/instruction/1915027
+++ /dev/null
@@ -1,27 +0,0 @@
-instruction: 0.816
-assembly: 0.781
-graphic: 0.759
-other: 0.744
-device: 0.634
-semantic: 0.632
-mistranslation: 0.442
-vnc: 0.284
-network: 0.181
-boot: 0.140
-socket: 0.116
-KVM: 0.044
-
-RISC-V 64, CPUs do ilegal 0x00 write with SMP
-
-When QEMU is runt like this:
-
-qemu-system-riscv64 -d unimp,guest_errors -smp 8
-
-Other harts will do a illegal write on address 0x00.
-
-This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute.
-
-Even with -smp 1 you will see the same errors. The problem is because there is nothing to run after OpenSBI jumps to the next stage.
-
-If you load a kernel you will not see the error messages.
-
diff --git a/results/classifier/semantic-bugs/instruction/1958 b/results/classifier/semantic-bugs/instruction/1958
deleted file mode 100644
index 8240e159e..000000000
--- a/results/classifier/semantic-bugs/instruction/1958
+++ /dev/null
@@ -1,34 +0,0 @@
-instruction: 0.931
-mistranslation: 0.877
-graphic: 0.858
-device: 0.805
-vnc: 0.766
-semantic: 0.679
-socket: 0.488
-other: 0.383
-KVM: 0.381
-network: 0.360
-boot: 0.359
-assembly: 0.268
-
-PPC msgsnd for DOORBELL CRITICAL masked by MSR[EE] instead of MSR[CE]
-Description of problem:
-When executing PPC instruction "msgsnd r3. with r3 = 0x08000001" an DOORBELL CRITICAL exception is raised on core number 1. But this exception is masked by MSR\[EE\] bit, the MSR\[EE\] should be set to 1 in core1 to get this exception. But the NXP E500MCRM.pdf reference manual indicates that MSR\[CE\] is the mask bit for DOORBELL_CRITICAL Exception.
-Additional information:
-In qemu-8.1.2/target/ppc/excp_helper.c i try to change in ppc_next_unmasked_interrupt_generic function:
-   
-```
-if (FIELD_EX64(env->msr, MSR, CE)) {
-    /* Critical doorbell */
-    if (env->pending_interrupts & PPC_INTERRUPT_CDOORBELL) {   <- move this part from (async_deliver != 0)
-        return PPC_INTERRUPT_CDOORBELL;
-     }
-     /* External critical interrupt */
-     if (env->pending_interrupts & PPC_INTERRUPT_CEXT) {
-         return PPC_INTERRUPT_CEXT;
-     }
-}
-```
- 
-
-And it seems to work in my case.
diff --git a/results/classifier/semantic-bugs/instruction/2074 b/results/classifier/semantic-bugs/instruction/2074
deleted file mode 100644
index 475ecd6df..000000000
--- a/results/classifier/semantic-bugs/instruction/2074
+++ /dev/null
@@ -1,33 +0,0 @@
-instruction: 0.908
-graphic: 0.839
-device: 0.680
-boot: 0.672
-semantic: 0.448
-other: 0.389
-mistranslation: 0.233
-vnc: 0.171
-socket: 0.147
-network: 0.129
-assembly: 0.101
-KVM: 0.093
-
-riscv64  cannot use the mret instruction to jump to the address corresponding to s mode
-Description of problem:
-I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800.
-and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened.
-It shows:
-[DEBUG]  Exception:          Instruction access fault
-[DEBUG]  Hart ID:            0
-[DEBUG]  Previous mode:      machine
-[DEBUG]  Bad instruction pc: 0x8103f7c0
-[DEBUG]  Bad address:        0x00000000
-[DEBUG]  Stored ra:          0x8103f7b8
-[DEBUG]  Stored sp:          0x82032f08
-Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret".
-So I can not jump to my kernel's load address.
-I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address?
-Steps to reproduce:
-1.download qemu
-2.download coreboot
-Additional information:
-When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000.
diff --git a/results/classifier/semantic-bugs/instruction/925 b/results/classifier/semantic-bugs/instruction/925
deleted file mode 100644
index 8d42ab6dc..000000000
--- a/results/classifier/semantic-bugs/instruction/925
+++ /dev/null
@@ -1,31 +0,0 @@
-instruction: 0.864
-graphic: 0.770
-device: 0.746
-network: 0.517
-other: 0.426
-assembly: 0.416
-vnc: 0.416
-socket: 0.394
-semantic: 0.338
-boot: 0.325
-KVM: 0.311
-mistranslation: 0.233
-
-AArch64 SVE2 LD/ST instructions segfault on MMIO addresses
-Description of problem:
-During execution of the following SVE2 instruction: `ld1b {z9.s}, p2/z, [x17, z26.s, sxtw]` with the following register state:
-```
-(gdb) p $x17
-$1 = 0xffffffe2
-(gdb) p $z26.s.u
-$2 = {0x0 <repeats 16 times>}
-(gdb) p $p2
-$3 = {0xc4, 0x0, 0x9d, 0x0, 0xe5, 0x0, 0x83, 0x0, 0x80, 0xce, 0x3f, 0x3, 0x0, 0x0, 0x0, 0x0, 0x46, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x56, 0x1a, 0x6e, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x50, 0xce, 0x94, 0x1, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x10, 0x38, 0x40, 0x3, 0x0, 0x0, 0x0, 0x0}
-```
-QEMU segfaults due to a null pointer access. Note that after translation this address is an MMIO address that points to a UART device.
-Additional information:
-A quick look at the implementation of the SVE2 load/store host memory access functions I've noticed that the `TLB_MMIO` flag is ignored in `sve_probe_page`, which means that users use the (null) host address as if it was pointing to real memory. This function (or the ones above it) should (probably) throw the appropriate external data abort, otherwise this needs to be instrumented to support reading from MMIO mapped devices.
-
-<details><summary>Reproducer seed for my future self</summary>
-S6008340160849309262|Q|cd4t|pq|w5|lK124
-</details>
diff --git a/results/classifier/semantic-bugs/mistranslation/1613817 b/results/classifier/semantic-bugs/mistranslation/1613817
deleted file mode 100644
index a275fd7fb..000000000
--- a/results/classifier/semantic-bugs/mistranslation/1613817
+++ /dev/null
@@ -1,130 +0,0 @@
-mistranslation: 0.697
-instruction: 0.679
-other: 0.653
-KVM: 0.623
-graphic: 0.617
-vnc: 0.599
-device: 0.558
-semantic: 0.550
-boot: 0.543
-assembly: 0.543
-network: 0.536
-socket: 0.523
-
-x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack
-
-This test program:
-
-# compile with: gcc -nostartfiles -nostdlib
-_start:         .globl  _start
-                mov     %ss,%eax
-                push    %rax
-                push    %rsp
-                pushf
-                mov     %cs,%eax
-                push    %rax
-                mov     $0x1234567812345678,%rax
-                push    %rax
-//qemu bug: ip=1234567812345678, should be ip=0000000000400abc:
-                iretq
-1:
-                jmp     1b
-
-should segfault on IRET instruction because return address on stack is invalid
-(it is not canonical). And it does, both on native CPU and in qemu.
-But there is a difference: on native CPU, it fails before instruction is executed,
-IOW: saved IP points to the failed IRET:
-
-# strace -i ./bad_ip_in_iret 
-[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0
-[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
- ^^^^^^^^^^^^^^^^-NOTE THIS
-[????????????????] +++ killed by SIGSEGV (core dumped) +++
-
-
-In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed:
-
-/ # strace -i ./bad_ip_in_iret
-[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0
-[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
- ^^^^^^^^^^^^^^^^-NOTE THIS
-[????????????????] +++ killed by SIGSEGV +++
-Segmentation fault
-
-Thus, the emulation is not the same as real CPU.
-
-This is not specific to IRET, the same happens with "far return" LRET,
-and with ordinary RET instructions as well.
-In qemu:
-
-/ # strace -i ./bad_ip_in_lret
-[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0
-[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
-[????????????????] +++ killed by SIGSEGV +++
-Segmentation fault
-/ # strace -i ./bad_ip_in_ret
-[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0
-[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
-[????????????????] +++ killed by SIGSEGV +++
-Segmentation fault
-
-# qemu-system-x86_64 --version
-QEMU emulator version 2.6.92(qemu-2.7.0-0.1.rc2.fc26), Copyright (c) 2003-2008 Fabrice Bellard
-
-Running it like this:
-
-qemu-system-x86_64 -no-reboot -kernel "$bzImage" -initrd initramfs.cpio -append "panic=1"
-
-(i.e. no KVM, no unusual options)
-
-
-The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
-If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
-
-
-Still happens with qemu 5.1.92
-
-I imagine the fix should be inserted here:
-
-static inline void helper_ret_protected(CPUX86State *env, int shift,
-                                        int is_iret, int addend,
-                                        uintptr_t retaddr)
-{
-    uint32_t new_cs, new_eflags, new_ss;
-    uint32_t new_es, new_ds, new_fs, new_gs;
-    uint32_t e1, e2, ss_e1, ss_e2;
-    int cpl, dpl, rpl, eflags_mask, iopl;
-    target_ulong ssp, sp, new_eip, new_esp, sp_mask;
-
-#ifdef TARGET_X86_64
-    if (shift == 2) {
-        sp_mask = -1;
-    } else
-#endif
-    {
-        sp_mask = get_sp_mask(env->segs[R_SS].flags);
-    }
-    sp = env->regs[R_ESP];
-    ssp = env->segs[R_SS].base;
-    new_eflags = 0; /* avoid warning */
-#ifdef TARGET_X86_64
-    if (shift == 2) {
-        POPQ_RA(sp, new_eip, retaddr);
-if (new_eip is not canonical) raise_exception_err_ra();  <==== HERE
-        POPQ_RA(sp, new_cs, retaddr);
-        new_cs &= 0xffff;
-        if (is_iret) {
-            POPQ_RA(sp, new_eflags, retaddr);
-        }
-    } else
-#endif
-
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/125
-
-
diff --git a/results/classifier/semantic-bugs/mistranslation/1830872 b/results/classifier/semantic-bugs/mistranslation/1830872
deleted file mode 100644
index ea6c495b1..000000000
--- a/results/classifier/semantic-bugs/mistranslation/1830872
+++ /dev/null
@@ -1,612 +0,0 @@
-mistranslation: 0.745
-other: 0.741
-vnc: 0.722
-instruction: 0.712
-KVM: 0.677
-semantic: 0.670
-graphic: 0.668
-device: 0.664
-assembly: 0.656
-boot: 0.623
-network: 0.606
-socket: 0.594
-
-AARCH64 to ARMv7 mistranslation in TCG
-
-The following guest code:
-
-  https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S
-
-implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI
-Development Kit II) library function. (CopyMem() basically has memmove()
-semantics, to provide a standard C analog here.) The relevant functions
-are InternalMemCopyMem() and __memcpy().
-
-When TCG translates this aarch64 code to x86_64, everything works fine.
-
-When TCG translates this aarch64 code to ARMv7, the destination area of
-the translated CopyMem() function becomes corrupted -- it differs from
-the intended source contents. Namely, in every 4096 byte block, the
-8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,
-instead of receiving the intended source value.
-
-I'm attaching two hexdumps of the same destination area:
-
-- "good.txt" is a hexdump of the destination area when CopyMem() was
-  translated to x86_64,
-
-- "bad.txt" is a hexdump of the destination area when CopyMem() was
-  translated to ARMv7.
-
-In order to assist with the analysis of this issue, I disassembled the
-aarch64 binary with "objdump". Please find the listing in
-"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at
-hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.
-
-And, I ran the guest on the ARMv7 host with "-d
-in_asm,op,op_opt,op_ind,out_asm". Please find the log in
-"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached.
-
-The TBs that correspond to (parts of) the InternalMemCopyMem() and
-__memcpy() functions are scattered over the TCG log file, but the offset
-between the "nice" disassembly from "DxeCore.objdump", and the in-RAM
-TBs in the TCG log, can be determined from the fact that there is a
-single prfm instruction in the entire binary. The instruction's offset
-is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy()
-function --, and its RAM address is 0x472d2180 in the TCG log. Thus the
-difference (= the load address of DxeCore.efi) is 0x472a7000.
-
-QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch
-'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21).
-
-The reproducer command line is (on an ARMv7 host):
-
-  qemu-system-aarch64 \
-    -display none \
-    -machine virt,accel=tcg \
-    -nodefaults \
-    -nographic \
-    -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \
-    -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \
-    -cpu cortex-a57 \
-    -chardev stdio,signal=off,mux=on,id=char0 \
-    -mon chardev=char0,mode=readline \
-    -serial chardev:char0
-
-The apparent symptom is an assertion failure *in the guest*, such as
-
-> ASSERT [DxeCore]
-> /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):
-> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength
-
-but that is only a (distant) consequence of the CopyMem()
-mistranslation, and resultant destination area corruption.
-
-Originally reported in the following two mailing list messages:
-- http://<email address hidden>
-- http://<email address hidden>
-
-
-
-Possibly related:
-[Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
-https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
-
-(qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when QEMU is built for i686)
-
-Note to self: try to reprodouce the present issue with QEMU built at eed5664238ea^ -- this LP has originally been filed about the tree at a4f667b67149, and that commit contains eed5664238ea. So checking at eed5664238ea^ might reveal a difference.
-
-
-Laszlo Ersek (Red Hat) <email address hidden> writes:
-
-> Possibly related:
-> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
-> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
->
-> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
-> QEMU is built for i686)
->
-> Note to self: try to reprodouce the present issue with QEMU built at
-> eed5664238ea^ -- this LP has originally been filed about the tree at
-> a4f667b67149, and that commit contains eed5664238ea. So checking at
-> eed5664238ea^ might reveal a difference.
-
-Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough
-cases.
-
---
-Alex Bennée
-
-
-
-Alex Bennée <email address hidden> writes:
-
-> Laszlo Ersek (Red Hat) <email address hidden> writes:
->
->> Possibly related:
->> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
->> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
->>
->> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
->> QEMU is built for i686)
->>
->> Note to self: try to reprodouce the present issue with QEMU built at
->> eed5664238ea^ -- this LP has originally been filed about the tree at
->> a4f667b67149, and that commit contains eed5664238ea. So checking at
->> eed5664238ea^ might reveal a difference.
->
-> Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough
-> cases.
-
-Actually I do see something with i386 host running the aarch64 memory
-test (although so far not with a armv7 host):
-
-  ./qemu-system-aarch64  -monitor none -display none -M virt -cpu max -display none -semihosting -kernel tests/memory
-
-Gives:
-
-  Reading u64 from 0x40213004 (offset 4):....Error 0, 0, 0, 0, 250, 249, 248, 255Test complete: FAILED
-
---
-Alex Bennée
-
-
-When running on 32 bit TCG backends a wide unaligned load ends up
-truncating data before returning to the guest. We specifically have
-the return type as uint64_t to avoid any premature truncation so we
-should use the same for the interim types.
-
-Hopefully fixes #1830872
-
-Signed-off-by: Alex Bennée <email address hidden>
----
- accel/tcg/cputlb.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
-index cdcc3771020..b796ab1cbea 100644
---- a/accel/tcg/cputlb.c
-+++ b/accel/tcg/cputlb.c
-@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
-         && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
-                     >= TARGET_PAGE_SIZE)) {
-         target_ulong addr1, addr2;
--        tcg_target_ulong r1, r2;
-+        uint64_t r1, r2;
-         unsigned shift;
-     do_unaligned_access:
-         addr1 = addr & ~(size - 1);
--- 
-2.20.1
-
-
-
-I confirm that QEMU works fine (for the use case originally reported in this LP ticket) when built at commit a6ae23831b, i.e. at the parent of eed5664238ea.
-
-В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а):
-> When running on 32 bit TCG backends a wide unaligned load ends up
-> truncating data before returning to the guest. We specifically have
-> the return type as uint64_t to avoid any premature truncation so we
-> should use the same for the interim types.
-> 
-> Hopefully fixes #1830872
-> 
-> Signed-off-by: Alex Bennée <email address hidden>
-> ---
->  accel/tcg/cputlb.c | 2 +-
->  1 file changed, 1 insertion(+), 1 deletion(-)
-> 
-> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
-> index cdcc3771020..b796ab1cbea 100644
-> --- a/accel/tcg/cputlb.c
-> +++ b/accel/tcg/cputlb.c
-> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
->          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
->                      >= TARGET_PAGE_SIZE)) {
->          target_ulong addr1, addr2;
-> -        tcg_target_ulong r1, r2;
-> +        uint64_t r1, r2;
->          unsigned shift;
->      do_unaligned_access:
->          addr1 = addr & ~(size - 1);
-
-Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my bug is separate from #1830872 ?
-
-I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler ..
-probably x86-64 testing on i686 requires either docker (I don't have this
-) or 'real' cross-compiler (build with glibc support).
-
-
-Sorry the patch in comment #5 wasn't visible when I wrote what would end up as comment #6. I'll test the patch later. Thanks!
-
-I managed to tweak the memory test enough to detect the failure on aarch64-on-armv7 and I the attached patch fixes it. Could you please double check with your test case?
-
-В сообщении от Monday 03 June 2019 18:51:40 Alex Bennée написал(а):
-> I managed to tweak the memory test enough to detect the failure on
-> aarch64-on-armv7 and I the attached patch fixes it. Could you please
-> double check with your test case?
-> 
-
-
-Hm, I manually applied path from LP(git diff disliked copypasted patch), 
-so for now git diff in qemu tree shows:
-
-diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
-index cdcc377102..b796ab1cbe 100644
---- a/accel/tcg/cputlb.c
-+++ b/accel/tcg/cputlb.c
-@@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
-         && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
-                     >= TARGET_PAGE_SIZE)) {
-         target_ulong addr1, addr2;
--        tcg_target_ulong r1, r2;
-+        uint64_t r1, r2;
-         unsigned shift;
-     do_unaligned_access:
-         addr1 = addr & ~(size - 1);
-lines 1-13/13 (END)                          
-
----------
-
-but x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg
-still hangs at 'booting the kernel" (it decompress OK)
-
-I make distclean'ed source tree and reconfigured it:
- ./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg  --cross-cc-x86_64="/opt/kgcc64/bin/x86_64-unknown-linux-gnu-gcc-6.5.0"
-
-next, make -j 5 and test.
-
-Hm.
-
-I tried debug switches, it seems to hang a bit differently for two runs:
-
-x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg -nographic -d in_asm,op,op_opt,op_ind,out_asm 
-
-=====================
-
-IN:
-0xffffffff810e8a63:  48 83 c3 64              addq     $0x64, %rbx
-0xffffffff810e8a67:  eb c2                    jmp      0xffffffff810e8a2b
-
-OP:
- ld_i32 tmp18,env,$0xfffffff0
- movi_i32 tmp19,$0x0
- brcond_i32 tmp18,tmp19,lt,$L0
-
- ---- ffffffff810e8a63 0000000000000000
- movi_i32 tmp2,$0x64
- movi_i32 tmp3,$0x0
- mov_i32 tmp0,rbx_0
- mov_i32 tmp1,rbx_1
- add2_i32 tmp0,tmp1,tmp0,tmp1,tmp2,tmp3
- mov_i32 rbx_0,tmp0
- mov_i32 rbx_1,tmp1
- mov_i32 cc_src_0,tmp2
- mov_i32 cc_src_1,tmp3
- mov_i32 cc_dst_0,tmp0
- mov_i32 cc_dst_1,tmp1
- discard cc_src2_0
- discard cc_src2_1
- discard cc_op
-
- ---- ffffffff810e8a67 0000000000000009
- movi_i32 cc_op,$0x9
- goto_tb $0x0
- movi_i32 tmp6,$0x810e8a2b
- movi_i32 tmp7,$0xffffffff
- st_i32 tmp6,env,$0x80
- st_i32 tmp7,env,$0x84
- exit_tb $0xf2f1c080
- set_label $L0
- exit_tb $0xf2f1c083
-
-OP after optimization and liveness analysis:
- ld_i32 tmp18,env,$0xfffffff0             dead: 1  pref=0xff
- movi_i32 tmp19,$0x0                      pref=0xff
- brcond_i32 tmp18,tmp19,lt,$L0            dead: 0 1
-
- ---- ffffffff810e8a63 0000000000000000
- movi_i32 tmp2,$0x64                      pref=0xff
- movi_i32 tmp3,$0x0                       pref=0xff
- add2_i32 tmp0,tmp1,rbx_0,rbx_1,tmp2,tmp3  dead: 2 3  pref=0xff,0xff
- mov_i32 rbx_0,tmp0                       sync: 0  dead: 1  pref=0xff
- mov_i32 rbx_1,tmp1                       sync: 0  dead: 1  pref=0xff
- mov_i32 cc_src_0,tmp2                    sync: 0  dead: 0 1  pref=0xff
- mov_i32 cc_src_1,tmp3                    sync: 0  dead: 0 1  pref=0xff
- mov_i32 cc_dst_0,rbx_0                   sync: 0  dead: 0 1  pref=0xff
- mov_i32 cc_dst_1,rbx_1                   sync: 0  dead: 0 1  pref=0xff
- discard cc_src2_0                        pref=0xff
- discard cc_src2_1                        pref=0xff
- discard cc_op                            pref=0xff mov_i32 cc_dst_0,tmp0
- mov_i32 cc_dst_1,tmp1
- discard cc_src2_0
- discard cc_src2_1
- discard cc_op
-
- ---- ffffffff810e8a55 0000000000000021
- movi_i32 cc_op,$0x21
- movi_i32 tmp20,$0x0
- movi_i32 tmp21,$0x0
- brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1
- goto_tb $0x0
- movi_i32 tmp6,$0x810e8a57
- movi_i32 tmp7,$0xffffffff
- st_i32 tmp6,env,$0x80
- st_i32 tmp7,env,$0x84
- exit_tb $0xf2f1c180
- set_label $L1
- goto_tb $0x1
- movi_i32 tmp6,$0x810e8a63
- movi_i32 tmp7,$0xffffffff
- st_i32 tmp6,env,$0x80
- st_i32 tmp7,env,$0x84
- exit_tb $0xf2f1c181
- set_label $L0
- exit_tb $0xf2f1c183
-
-OP after optimization and liveness analysis:
- ld_i32 tmp18,env,$0xfffffff0             dead: 1  pref=0xff
- movi_i32 tmp19,$0x0                      pref=0xff
- brcond_i32 tmp18,tmp19,lt,$L0            dead: 0 1
-
- ---- ffffffff810e8a4c 0000000000000000
-
- ---- ffffffff810e8a52 0000000000000000
- movi_i32 tmp1,$0x0                       pref=0xff
- movi_i32 tmp0,$0x64                      pref=0xff
- mov_i32 r14_0,tmp0                       sync: 0  dead: 1  pref=0xf8
- mov_i32 r14_1,tmp1                       sync: 0  dead: 1  pref=0xf8
- call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op  sync: 0 1  dead: 0 1 2 3 4 5 6 7 8  pref=none,none
- mov_i32 cc_dst_0,r14_0                   sync: 0  dead: 0 1  pref=0xff
- mov_i32 cc_dst_1,r14_1                   sync: 0  dead: 0 1  pref=0xffУбито
-
-(killed by me)
-
-==================
-
-IN:
-0xffffffff810e8a61:  eb ef                    jmp      0xffffffff810e8a52
-
-OP:
- ld_i32 tmp18,env,$0xfffffff0
- movi_i32 tmp19,$0x0
- brcond_i32 tmp18,tmp19,lt,$L0
-
- ---- ffffffff810e8a61 0000000000000000
- goto_tb $0x0
- movi_i32 tmp6,$0x810e8a52
- movi_i32 tmp7,$0xffffffff
- st_i32 tmp6,env,$0x80
- st_i32 tmp7,env,$0x84
- exit_tb $0xf2f22900
- set_label $L0
- exit_tb $0xf2f22903
-
-OP after optimization and liveness analysis:
- ld_i32 tmp18,env,$0xfffffff0             dead: 1  pref=0xff
- movi_i32 tmp19,$0x0                      pref=0xff
- brcond_i32 tmp18,tmp19,lt,$L0            dead: 0 1
-
- ---- ffffffff810e8a61 0000000000000000
- goto_tb $0x0
- movi_i32 tmp6,$0x810e8a52                pref=0xff
- movi_i32 tmp7,$0xffffffff                pref=0xff
- st_i32 tmp6,env,$0x80                    dead: 0
- st_i32 tmp7,env,$0x84                    dead: 0 1
- exit_tb $0xf2f22900
- set_label $L0
- exit_tb $0xf2f22903
-
-OUT: [size=56]
-0xf2f22980:  8b 5d f0                 movl     -0x10(%ebp), %ebx
-0xf2f22983:  85 db                    testl    %ebx, %ebx
-0xf2f22985:  0f 8c 23 00 00 00        jl       0xf2f229ae
-0xf2f2298b:  e9 00 00 00 00           jmp      0xf2f22990
-0xf2f22990:  c7 85 80 00 00 00 52 8a  movl     $0x810e8a52, 0x80(%ebp)
-0xf2f22998:  0e 81
-0xf2f2299a:  c7 85 84 00 00 00 ff ff  movl     $0xffffffff, 0x84(%ebp)
-0xf2f229a2:  ff ff
-0xf2f229a4:  b8 00 29 f2 f2           movl     $0xf2f22900, %eax
-0xf2f229a9:  e9 69 46 c9 ff           jmp      0xf2bb7017
-0xf2f229ae:  b8 03 29 f2 f2           movl     $0xf2f22903, %eax
-0xf2f229b3:  e9 5f 46 c9 ff           jmp      0xf2bb7017
-
-----------------
-IN:
-0xffffffff810e8a52:  49 ff ce                 decq     %r14
-0xffffffff810e8a55:  74 0c                    je       0xffffffff810e8a63
-
-OP:
- ld_i32 tmp18,env,$0xfffffff0
- movi_i32 tmp19,$0x0
- brcond_i32 tmp18,tmp19,lt,$L0
-
- ---- ffffffff810e8a52 0000000000000000
- mov_i32 tmp0,r14_0
- mov_i32 tmp1,r14_1
- mov_i32 tmp0,r14_0
- mov_i32 tmp1,r14_1
- movi_i32 tmp20,$0xffffffff
- movi_i32 tmp21,$0xffffffff
- add2_i32 tmp0,tmp1,tmp0,tmp1,tmp20,tmp21
- mov_i32 r14_0,tmp0
- mov_i32 r14_1,tmp1
- call cc_compute_c,$0x5,$2,cc_src_0,cc_src_1,cc_dst_0,cc_dst_1,cc_src_0,cc_src_1,cc_src2_0,cc_src2_1,cc_op
- mov_i32 cc_dst_0,tmp0
- mov_i32 cc_dst_1,tmp1
- discard cc_src2_0
- discard cc_src2_1
- discard cc_op
-
- ---- ffffffff810e8a55 0000000000000021 mov_i32 cc_dst_0,r14_0                   sync: 0  dead: 1  pref=0xff
- mov_i32 cc_dst_1,r14_1                   sync: 0  dead: 1  pref=0xff
- discard cc_src2_0                        pref=0xff
- discard cc_src2_1                        pref=0xff
- discard cc_op                            pref=0xff
-
- ---- ffffffff810e8a55 0000000000000021
- movi_i32 cc_op,$0x21                     sync: 0  dead: 0  pref=0xff
- movi_i32 tmp20,$0x0                      pref=0xff
- movi_i32 tmp21,$0x0                      pref=0xff
- brcond2_i32 cc_dst_0,cc_dst_1,tmp20,tmp21,eq,$L1  dead: 0 1 2 3
- goto_tb $0x0
- movi_i32 tmp6,$0x810e8a57                pref=0xff
- movi_i32 tmp7,$0xffffffff                pref=0xff
- st_i32 tmp6,env,$0x80                    dead: 0
- st_i32 tmp7,env,$0x84                    dead: 0 1
- exit_tb $0xf2f229c0
- set_label $L1
- goto_tb $0x1
- movi_i32 tmp6,$0x810e8a63                pref=0xff movi_i32 cc_op,$0x9                      sync: 0  dead: 0  pref=0xff
- goto_tb $0x0
- movi_i32 tmp6,$0x810e8a2b                pref=0xff
- movi_i32 tmp7,$0xffffffff                pref=0xff
- st_i32 tmp6,env,$0x80                    dead: 0
- st_i32 tmp7,env,$0x84                    dead: 0 1
- exit_tb $0xf2f22b40
- set_label $L0
- exit_tb $0xf2f22b43
-
-OUT: [size=116]
-0xf2f22bc0:  8b 5d f0                 movl     -0x10(%ebp), %ebx
-0xf2f22bc3:  85 db                    testl    %ebx, %ebx
-0xf2f22bc5:  0f 8c 5f 00 00 00        jl       0xf2f22c2a
-0xf2f22bcb:  8b 5d 18                 movl     0x18(%ebp), %ebx
-0xf2f22bce:  8b 75 1c                 movl     0x1c(%ebp), %esi
-0xf2f22bd1:  83 c3 64                 addl     $0x64, %ebx
-0xf2f22bd4:  83 d6 00                 adcl     $0, %esi
-0xf2f22bd7:  89 5d 18                 movl     %ebx, 0x18(%ebp)
-Убито
-
-=============================
-
-try kernel I use (it works with qemu compiiled under 64-bit Slackware, and also with kvm on 32-bit x86)
-
-sha256sum /boot/bzImage-4.12.0-x64
-b4183376de17e8ea7a25094b7a526e99bcb8339b8703090684c93e0e0a50d284  /boot/bzImage-4.12.0-x64
-
-
-(+Igor)
-
-On 06/03/19 17:01, Alex Bennée wrote:
-> When running on 32 bit TCG backends a wide unaligned load ends up
-> truncating data before returning to the guest. We specifically have
-> the return type as uint64_t to avoid any premature truncation so we
-> should use the same for the interim types.
-> 
-> Hopefully fixes #1830872
-> 
-> Signed-off-by: Alex Bennée <email address hidden>
-> ---
->  accel/tcg/cputlb.c | 2 +-
->  1 file changed, 1 insertion(+), 1 deletion(-)
-> 
-> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
-> index cdcc3771020..b796ab1cbea 100644
-> --- a/accel/tcg/cputlb.c
-> +++ b/accel/tcg/cputlb.c
-> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
->          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
->                      >= TARGET_PAGE_SIZE)) {
->          target_ulong addr1, addr2;
-> -        tcg_target_ulong r1, r2;
-> +        uint64_t r1, r2;
->          unsigned shift;
->      do_unaligned_access:
->          addr1 = addr & ~(size - 1);
-> 
-
-Applied on top of commit ad88e4252f09c2956b99c90de39e95bab2e8e7af:
-
-Tested-by: Laszlo Ersek <email address hidden>
-
-Thanks!
-Laszlo
-
-
-
-Andrew Randrianasulu <email address hidden> writes:
-
-> В сообщении от Monday 03 June 2019 18:01:20 Alex Bennée написал(а):
->> When running on 32 bit TCG backends a wide unaligned load ends up
->> truncating data before returning to the guest. We specifically have
->> the return type as uint64_t to avoid any premature truncation so we
->> should use the same for the interim types.
->>
->> Hopefully fixes #1830872
->>
->> Signed-off-by: Alex Bennée <email address hidden>
->> ---
->>  accel/tcg/cputlb.c | 2 +-
->>  1 file changed, 1 insertion(+), 1 deletion(-)
->>
->> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
->> index cdcc3771020..b796ab1cbea 100644
->> --- a/accel/tcg/cputlb.c
->> +++ b/accel/tcg/cputlb.c
->> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
->>          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
->>                      >= TARGET_PAGE_SIZE)) {
->>          target_ulong addr1, addr2;
->> -        tcg_target_ulong r1, r2;
->> +        uint64_t r1, r2;
->>          unsigned shift;
->>      do_unaligned_access:
->>          addr1 = addr & ~(size - 1);
->
-> Unfortunatly, this doesn't fix 32-bit qemu-system-x86_64 .... so, my
-> bug is separate from #1830872 ?
-
-I think you've hit two - one of which we have just fixed. With my
-expanded memory test on i386 I'm seeing a hang but it's ok @
-pull-demacro-softmmu-100519-1. Unfortunately bisecting through the slirp
-move and other i386 Werror stuff is proving painful.
-
->
-> I also was unable to convince qemu to use my kernel-only x86_64 gcc 6.5.0 cross-compiler ..
-> probably x86-64 testing on i686 requires either docker (I don't have this
-> ) or 'real' cross-compiler (build with glibc support).
-
-
---
-Alex Bennée
-
-
-On Mon,  3 Jun 2019 16:01:20 +0100
-Alex Bennée <email address hidden> wrote:
-
-> When running on 32 bit TCG backends a wide unaligned load ends up
-> truncating data before returning to the guest. We specifically have
-> the return type as uint64_t to avoid any premature truncation so we
-> should use the same for the interim types.
-> 
-> Hopefully fixes #1830872
-> 
-> Signed-off-by: Alex Bennée <email address hidden>
-
-Fixes arm/virt bios-tables-test for me, so
-
-Tested-by: Igor Mammedov <email address hidden>
-
-> ---
->  accel/tcg/cputlb.c | 2 +-
->  1 file changed, 1 insertion(+), 1 deletion(-)
-> 
-> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
-> index cdcc3771020..b796ab1cbea 100644
-> --- a/accel/tcg/cputlb.c
-> +++ b/accel/tcg/cputlb.c
-> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, TCGMemOpIdx oi,
->          && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
->                      >= TARGET_PAGE_SIZE)) {  
->          target_ulong addr1, addr2;
-> -        tcg_target_ulong r1, r2;
-> +        uint64_t r1, r2;
->          unsigned shift;
->      do_unaligned_access:
->          addr1 = addr & ~(size - 1);
-
-
-
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8c79b288513587e960b
-
diff --git a/results/classifier/semantic-bugs/mistranslation/83 b/results/classifier/semantic-bugs/mistranslation/83
deleted file mode 100644
index ca61d874d..000000000
--- a/results/classifier/semantic-bugs/mistranslation/83
+++ /dev/null
@@ -1,14 +0,0 @@
-mistranslation: 0.859
-instruction: 0.857
-device: 0.813
-other: 0.511
-graphic: 0.374
-boot: 0.370
-socket: 0.204
-semantic: 0.165
-vnc: 0.149
-network: 0.095
-assembly: 0.028
-KVM: 0.001
-
-QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit
diff --git a/results/classifier/semantic-bugs/semantic/1428352 b/results/classifier/semantic-bugs/semantic/1428352
deleted file mode 100644
index b63b8cedc..000000000
--- a/results/classifier/semantic-bugs/semantic/1428352
+++ /dev/null
@@ -1,63 +0,0 @@
-semantic: 0.788
-other: 0.739
-graphic: 0.673
-mistranslation: 0.665
-instruction: 0.659
-assembly: 0.653
-device: 0.631
-vnc: 0.613
-KVM: 0.595
-network: 0.538
-boot: 0.531
-socket: 0.491
-
-SYSRET instruction incorrectly implemented
-
-The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic:
-
-SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *)
-
-Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here:
-
-http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html
-
-[...]
-        SS(SEL) = IA32_STAR[63:48] + 8;
-        SS(PL) = 0x3;
-[...]
-
-In other words, the value of the %ss register is supposed to be loaded from  bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call.
-
-However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this:
-
-        cpu_x86_load_seg_cache(env, R_SS, selector + 8,
-                               0, 0xffffffff,
-                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
-                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
-                               DESC_W_MASK | DESC_A_MASK);
-
-It should look like this:
-
-        cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3,
-                               0, 0xffffffff,
-                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
-                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
-                               DESC_W_MASK | DESC_A_MASK);
-
-The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss).
-
-The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.)
-
-This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :)
-
-Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM.
-
-The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware.
-
-- Bill (<email address hidden>)
-
-
-
-If I've got that right, this has been fixed here:
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ac57622985220de0
-
diff --git a/results/classifier/semantic-bugs/semantic/1923197 b/results/classifier/semantic-bugs/semantic/1923197
deleted file mode 100644
index 06e794798..000000000
--- a/results/classifier/semantic-bugs/semantic/1923197
+++ /dev/null
@@ -1,149 +0,0 @@
-semantic: 0.907
-mistranslation: 0.879
-other: 0.869
-assembly: 0.855
-instruction: 0.854
-socket: 0.832
-device: 0.813
-graphic: 0.805
-KVM: 0.794
-vnc: 0.737
-boot: 0.724
-network: 0.710
-
-RISC-V priviledged instruction error
-
-Hello when performing an MRET with MPP set to something else than 0b11 in MSTATUS, 'Invalid Instruction' exception will be triggered. The problem appeared in code after version 5.2.0.
-
-<pre>
-  # setup interrupt handling for monitor mode
-  la t0, entry_loop
-  la t1, entry_trap
-  li t2, 0x888
-  li t3, 0x1880 # MPP in MSTATUS selects to which mode to return & MPIE selects if to enable interrupts after MRET
-  csrw mepc, t0
-  csrw mtvec, t1
-  csrs mie, t2
-  csrs mstatus, t3
-
-  # if supervisor mode not supported, then loop forever
-  csrr t0, misa
-  li t1, 0x40000
-  and t2, t1, t0
-  beqz t2, 1f
-
-  # setup interrupt i& exception delegation for supervisor mode
-  li t0, 0xc0000000 # 3 GiB (entry address of supervisor)
-  li t1, 0x1000
-  #li t2, 0x300 # bit 8 & 9 is for ecall from user & supervisor mode
-  #li t3, 0x222
-  csrw mepc, t0
-  csrc mstatus, t1
-  #csrs medeleg, t2
-  #csrs mideleg, t3
-
-  # pass mhartid as first parameter to supervisor
-  csrr a0, mhartid
-
-1:
-  mret
-</pre>
-
-I'm guessing that this is a bug in your guest as it hasn't configured PMP regions.
-
-From the RISC-V spec:
-
-"
-If no PMP entry matches an M-mode access, the access succeeds. If no PMP entry matches an
-S-mode or U-mode access, but at least one PMP entry is implemented, the access fails.
-"
-
-Confusingly implemented here means implemented in hardware, not just configured.
-
-You can check this by reverting this QEMU commit:
-
-commit d102f19a2085ac931cb998e6153b73248cca49f1
-Author: Atish Patra <email address hidden>
-Date:   Wed Dec 23 11:25:53 2020 -0800
-
-    target/riscv/pmp: Raise exception if no PMP entry is configured
-    
-    As per the privilege specification, any access from S/U mode should fail
-    if no pmp region is configured.
-    
-    Signed-off-by: Atish Patra <email address hidden>
-    Reviewed-by: Alistair Francis <email address hidden>
-    Message-id: <email address hidden>
-    Signed-off-by: Alistair Francis <email address hidden>
-
-
-Hello Francis,
-
-I'll configure PMP than do the test again. Sorry I hadn't understood what
-changed between version 5.2 and 6.0-rc2, since my code worked before.
-
-Best regards,
-Teodori Serge
-
-On Thu, 15 Apr 2021, 06:15 Alistair Francis, <email address hidden>
-wrote:
-
-> I'm guessing that this is a bug in your guest as it hasn't configured
-> PMP regions.
->
-> >From the RISC-V spec:
->
-> "
-> If no PMP entry matches an M-mode access, the access succeeds. If no PMP
-> entry matches an
-> S-mode or U-mode access, but at least one PMP entry is implemented, the
-> access fails.
-> "
->
-> Confusingly implemented here means implemented in hardware, not just
-> configured.
->
-> ** Changed in: qemu
->        Status: Confirmed => Invalid
->
-> --
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1923197
->
-> Title:
->   RISC-V priviledged instruction error
->
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions
->
-
-
-We fixed a bug to make QEMU act more like hardware, which now means that PMP must be configured in M-mode.
-
-Hello Francis,
-
-Yes thank you. I added code to setup a basic PMP and it works now. Thank
-you and best regards,
-
-Teodori Serge
-
-On Sun, 18 Apr 2021, 05:55 Alistair Francis, <email address hidden>
-wrote:
-
-> We fixed a bug to make QEMU act more like hardware, which now means that
-> PMP must be configured in M-mode.
->
-> --
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1923197
->
-> Title:
->   RISC-V priviledged instruction error
->
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions
->
-
-