1 files changed, 0 insertions, 101 deletions
diff --git a/results/classifier/118/debug/1913913 b/results/classifier/118/debug/1913913
deleted file mode 100644
index 27942809..00000000
--- a/results/classifier/118/debug/1913913
+++ /dev/null
@@ -1,101 +0,0 @@
-debug: 0.875
-i386: 0.853
-architecture: 0.769
-user-level: 0.769
-device: 0.756
-register: 0.747
-performance: 0.731
-PID: 0.730
-permissions: 0.725
-files: 0.722
-graphic: 0.695
-kernel: 0.672
-socket: 0.665
-network: 0.653
-semantic: 0.633
-risc-v: 0.619
-ppc: 0.584
-peripherals: 0.578
-mistranslation: 0.573
-arm: 0.551
-hypervisor: 0.523
-virtual: 0.520
-vnc: 0.515
-boot: 0.487
-assembly: 0.476
-VMM: 0.462
-TCG: 0.454
-x86: 0.392
-KVM: 0.330
-
-i386-linux-user returns -1 in sigcontext->trapno 
-
-QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally.
-
-Certain 16-bit windows programs crash WINE under QEMU linux-user with:
-
-0084:err:seh:segv_handler Got unexpected trap -1
-wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger...
-
-They run correctly on native i386.
-
-Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). 
-
-It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE.
-
-However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error.
-
-I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this.
-
-I have identified the core issue:
-
-Synchronous exceptions/traps in linux-user/i386/cpu_loop.c are handled as a return value from cpu_exec().
-cpu_exec() resets exception_index to -1 in  cpu_handle_exception()
-
-This means that queue_signal() (called from gen_signal() in the cpu loop) does not store the actual  CPU trap value anywhere.
-
-If we abuse env->exception_nr to store the trapnr, and retrieve it from there in setup_sigcontext() in linux-user/i386/signal.c instead of using exception_index (which will be set to -1 for all synchronous excptions).
-
-The main issue is if this breaks asynchronous signals, and under what conditions exception_nr should be set to -1.
-
-
-
-
-
-
-
- 
-
-
-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.]
-