other: 0.225
semantic: 0.109
files: 0.093
debug: 0.090
device: 0.073
performance: 0.070
PID: 0.063
graphic: 0.051
network: 0.046
vnc: 0.040
socket: 0.039
permissions: 0.037
KVM: 0.033
boot: 0.030
debug: 0.771
files: 0.040
other: 0.036
performance: 0.027
PID: 0.025
network: 0.021
semantic: 0.020
boot: 0.011
device: 0.010
socket: 0.009
permissions: 0.009
graphic: 0.008
vnc: 0.007
KVM: 0.006

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.]