restructure results

1 files changed, 0 insertions, 101 deletions

diff --git a/results/classifier/118/peripherals/1886097 b/results/classifier/118/peripherals/1886097
deleted file mode 100644
index 465e2880..00000000
--- a/results/classifier/118/peripherals/1886097
+++ /dev/null
@@ -1,101 +0,0 @@
-peripherals: 0.846
-user-level: 0.818
-mistranslation: 0.806
-semantic: 0.774
-graphic: 0.769
-debug: 0.742
-hypervisor: 0.741
-assembly: 0.713
-risc-v: 0.705
-architecture: 0.704
-permissions: 0.703
-VMM: 0.693
-network: 0.673
-ppc: 0.672
-vnc: 0.670
-device: 0.661
-virtual: 0.655
-performance: 0.653
-kernel: 0.648
-TCG: 0.645
-arm: 0.602
-register: 0.602
-PID: 0.600
-KVM: 0.571
-x86: 0.550
-socket: 0.547
-boot: 0.514
-files: 0.469
-i386: 0.308
-
-Error in user-mode calculation of ELF program's brk
-
-There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments:
-
-  Program Headers:
-    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
-    EXIDX          0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R   0x4
-    PHDR           0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R   0x1000
-    LOAD           0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R   0x1000
-    LOAD           0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000
-    LOAD           0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW  0x10000
-    NOTE           0x000114 0x00010114 0x00010114 0x00044 0x00044 R   0x4
-    TLS            0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R   0x4
-    GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x8
-    GNU_RELRO      0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R   0x1
-    LOAD           0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000
-    LOAD           0x098000 0x00030000 0x00030000 0x01000 0x01000 RW  0x1000
-
-The call to set_brk in Linux's binfmt_elf.c receives these arguments:
-
-  set_brk(0xa3160, 0xa3160, 1)
-  
-Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case).
-
-I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is
-
-  LOAD           0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW  0x10000
-    
-which overlaps with the TLS segment:
-
-    TLS            0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R   0x4
-    
-However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same.
-
-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" within the next 60 days (otherwise it will get
-closed as "Expired"). We will then eventually migrate the ticket auto-
-matically to the new system (but you won't be the reporter of the bug
-in the new system and thus won't get notified on changes anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-
-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/276
-
-