1 files changed, 101 insertions, 0 deletions
diff --git a/results/classifier/118/debug/1913913 b/results/classifier/118/debug/1913913
new file mode 100644
index 000000000..27942809f
--- /dev/null
+++ b/results/classifier/118/debug/1913913
@@ -0,0 +1,101 @@
+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.]
+