1 files changed, 97 insertions, 0 deletions
diff --git a/results/classifier/118/none/1031920 b/results/classifier/118/none/1031920
new file mode 100644
index 000000000..c66ac312f
--- /dev/null
+++ b/results/classifier/118/none/1031920
@@ -0,0 +1,97 @@
+files: 0.769
+debug: 0.759
+architecture: 0.746
+arm: 0.743
+user-level: 0.741
+performance: 0.728
+mistranslation: 0.709
+device: 0.672
+semantic: 0.657
+assembly: 0.623
+graphic: 0.603
+PID: 0.594
+kernel: 0.589
+ppc: 0.577
+network: 0.558
+peripherals: 0.553
+register: 0.536
+x86: 0.484
+TCG: 0.473
+permissions: 0.471
+hypervisor: 0.466
+socket: 0.461
+risc-v: 0.457
+vnc: 0.412
+virtual: 0.405
+boot: 0.392
+VMM: 0.376
+KVM: 0.358
+i386: 0.352
+
+Linux user gdbserver does not respond to remote  `Ctrl-C' interrupts
+
+The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver:
+
+$ qemu-arm -g 1234 a.out
+
+and then connecting from gdb:
+
+(gdb) target remote :1234
+Remote debugging using :1234
+[New Remote target]
+[Switching to Remote target]
+0x00008ba8 in _start ()
+(gdb) b main
+Breakpoint 1 at 0x8cb0: file hello.c, line 5.
+(gdb) cont
+Continuing.
+
+Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5
+5	  int n = 0;
+(gdb) l
+1	#include <stdio.h>
+2	
+3	int main (int argc, char **argv)
+4	{
+5	  int n = 0;
+6	
+7	  for (;;) {
+8	     printf ("Hello, World!\n");
+9	     sleep (5);
+10	  }
+(gdb) cont
+Continuing.
+^C^CInterrupted while waiting for the program.
+Give up (and stop debugging it)? (y or n) y
+
+Notice that the `Ctrl-C' interrupts are ignored.
+
+I have encountered that issue recently, and started some analysis.
+
+The issue is due to  the fact that in qemu, gdbstub no longer reads the communication channel once
+the debugged process is resumed with "cont".
+Another way to say that, is that communication with gdb is only possible once the process thread execution
+is re-routed in the gdb handler.
+
+I am working on a fix.
+
+The fix will consist in having an additional thread, launched that the internal gdbserver startup, 
+that will be wakeup when the debugged process is resumed. 
+That thread will be waiting on the communication channel for the eventually incoming CTRL-C request (0x3)
+I start to have promising results but it still needs some testing.
+
+Meanwhile, (this should likely be a separate discussion thread, but is somehow related with the named issue above)  ,
+I also noticed that with multithreaded 
+processes, a breakpoint does not suspend all the threads when it is hit. 
+This is a little bit annoying, and does not match the expected behaviour that is typically seen on a pure native gdb debugging
+session.
+
+Once it is ready I will post a patch to qemu mailing list
+
+Best regards
+Thierry
+
+Has the fix mentioned in comment #1 been included in the QEMU repository?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+