add results

5 files changed, 4 insertions, 158 deletions

diff --git a/results/classifier/semantic-bugs/1079080 b/results/classifier/semantic-bugs/1079080
index c3723248d..07054d7c5 100644
--- a/results/classifier/semantic-bugs/1079080
+++ b/results/classifier/semantic-bugs/1079080
@@ -1,15 +1,3 @@
-instruction: 0.967
-graphic: 0.903
-device: 0.901
-semantic: 0.833
-network: 0.755
-socket: 0.707
-vnc: 0.648
-boot: 0.648
-other: 0.637
-mistranslation: 0.619
-assembly: 0.187
-KVM: 0.100
 
 ARM instruction "srs" wrong behaviour
 
@@ -21,23 +9,4 @@ When executing this instruction, the register stored is CPSR instead of SPSR.
 
 Context:
 Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line:
-qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic
-
-It looks like this is only a problem in Thumb mode; the equivalent bug in ARM mode was fixed in commit c67b6b71 back in 2009.
-
-Can you make the test case dtb and image available? That would help in testing...
-
-
-
-
-
-
-Thanks -- I've submitted a patch which fixes this: http://patchwork.ozlabs.org/patch/220748/
-
-If you'd like to give me a name/email [format "Full Name <email address hidden>"] I can credit you in a Reported-by: tag in the commit message...
-
-
-You are welcome. 
-Credit info you need: Cesson Vincent <email address hidden>
-Thank you for fixing it!
-
+qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic
\ No newline at end of file
diff --git a/results/classifier/semantic-bugs/1377 b/results/classifier/semantic-bugs/1377
index f3d87d4fe..441707f13 100644
--- a/results/classifier/semantic-bugs/1377
+++ b/results/classifier/semantic-bugs/1377
@@ -1,15 +1,3 @@
-instruction: 0.973
-assembly: 0.847
-device: 0.773
-vnc: 0.768
-graphic: 0.742
-boot: 0.462
-socket: 0.412
-KVM: 0.326
-semantic: 0.321
-network: 0.279
-other: 0.095
-mistranslation: 0.073
 
 x86 CVT* series instructions fault
 Description of problem:
diff --git a/results/classifier/semantic-bugs/1809546 b/results/classifier/semantic-bugs/1809546
index dfeb2f575..f02d92551 100644
--- a/results/classifier/semantic-bugs/1809546
+++ b/results/classifier/semantic-bugs/1809546
@@ -1,15 +1,3 @@
-semantic: 0.913
-instruction: 0.876
-device: 0.860
-other: 0.855
-boot: 0.852
-assembly: 0.850
-graphic: 0.848
-network: 0.811
-mistranslation: 0.754
-vnc: 0.735
-socket: 0.612
-KVM: 0.608
 
 Writing a byte to a pl011 SFR overwrites the whole SFR
 
@@ -54,37 +42,4 @@ Compiling the original C code with optimizations makes the driver work. It compi
 
 Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code.
 
-I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR.
-
-
-
-Adding the link script.
-
-Yes, our PL011 implementation assumes that you only ever access the 32-bit registers with full width 32-bit word reads and writes. Don't try to do byte accesses to them. The PL011 data sheet doesn't specifically say that partial-width accesses to registers are permitted, so I think that trying to access offset 0x39 falls under the general note in section 3.1 that attempting to access reserved or unused address locations can result in unpredictable behaviour.
-
-You need to make sure you write your C code in a manner which enforces that accesses to device registers are done as single 32-bit accesses, and the compiler does not silently break them down into multiple reads and writes, or you will be in for a lot of pain trying to figure out what is going on if the compiler ever does it with registers that are write-to-clear or similar behaviour. Linux, for instance, does this by having readl() and writel() functions that end up doing inline asm of ldr/str instructions.
-
-
-Thanks for the response.
-
-I don't think section 3.1 applies to 8-bit accesses. That is specifically about reserved locations, and neither offset 0x38 nor 0x39 are reserved, so I think it's a matter of whether 32-bit access is required or not.
-
-From what I usually see in ARM documentation, 32-bit access is explicitly mentioned when required. For the PL011, it's mentioned for the UARTPeriphID_n registers, for instance. In many other cases access size depends on the implementation and the corresponding memory mapping of that implementation.
-
-I understand that *in practice* you should ensure single-access writes unless doing otherwise is explicitly allowed. However, in cases like the PL011 it seems ambiguous whether that is actually required, so it seems like the best choice would be to explicitly document it for the QEMU implementation. That would save some guesswork.
-
-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 please 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.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
+I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR.
\ No newline at end of file
diff --git a/results/classifier/semantic-bugs/1824778 b/results/classifier/semantic-bugs/1824778
index d9e3e95db..aa50d5d8c 100644
--- a/results/classifier/semantic-bugs/1824778
+++ b/results/classifier/semantic-bugs/1824778
@@ -1,15 +1,3 @@
-instruction: 0.756
-device: 0.493
-semantic: 0.280
-graphic: 0.275
-network: 0.264
-other: 0.245
-boot: 0.202
-vnc: 0.194
-socket: 0.151
-mistranslation: 0.124
-KVM: 0.054
-assembly: 0.052
 
 PowerPC64: tlbivax does not work for addresses above 4G
 
@@ -18,13 +6,4 @@ Changing the argument ea from uint32_t to target_ulong for the function booke206
 
 I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change.
 
-Issue can be seen in all version of QEMU.
-
-
-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/52
-
-
+Issue can be seen in all version of QEMU.
\ No newline at end of file
diff --git a/results/classifier/semantic-bugs/1898954 b/results/classifier/semantic-bugs/1898954
index 77df51de8..b95dfb215 100644
--- a/results/classifier/semantic-bugs/1898954
+++ b/results/classifier/semantic-bugs/1898954
@@ -1,15 +1,3 @@
-instruction: 0.923
-mistranslation: 0.880
-boot: 0.854
-graphic: 0.850
-other: 0.845
-KVM: 0.778
-device: 0.762
-semantic: 0.752
-socket: 0.648
-network: 0.624
-assembly: 0.575
-vnc: 0.567
 
 x86 f1 opcode hangs qemu
 
@@ -37,37 +25,4 @@ my startup code is
 "d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc
 ---
 also same flaw if i change above section to
-"d:\programs\qemu\qemu-system-i386.exe"
-
-The QEMU project is currently moving 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 the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" or "Confirmed" within the next 60 days (other-
-wise it will get closed as "Expired"). We will then eventually migrate
-the ticket automatically to the new system (but you won't be the reporter
-of the bug in the new system and thus you won't get notified on changes
-anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
+"d:\programs\qemu\qemu-system-i386.exe"
\ No newline at end of file