diff options
Diffstat (limited to 'results/classifier/111/review/1031920')
| -rw-r--r-- | results/classifier/111/review/1031920 | 96 |
1 files changed, 96 insertions, 0 deletions
diff --git a/results/classifier/111/review/1031920 b/results/classifier/111/review/1031920 new file mode 100644 index 00000000..f8d9098f --- /dev/null +++ b/results/classifier/111/review/1031920 @@ -0,0 +1,96 @@ +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.] + |