From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmO5u-0002sD-Bo for qemu-devel@nongnu.org; Wed, 14 Oct 2015 11:35:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmO5q-0004S6-4n for qemu-devel@nongnu.org; Wed, 14 Oct 2015 11:35:58 -0400 Received: from indium.canonical.com ([91.189.90.7]:41119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmO5p-0004Rn-Uk for qemu-devel@nongnu.org; Wed, 14 Oct 2015 11:35:54 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.76 #1 (Debian)) id 1ZmO5p-00060L-Ah for ; Wed, 14 Oct 2015 15:35:53 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 3F4042E80C8 for ; Wed, 14 Oct 2015 15:35:53 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2015 15:27:25 -0000 From: thierry bultel Sender: bounces@canonical.com References: <20120801202321.9879.66283.malonedeb@wampee.canonical.com> Message-Id: <20151014152726.18016.15778.malone@soybean.canonical.com> Errors-To: bounces@canonical.com Subject: [Qemu-devel] [Bug 1031920] Re: Linux user gdbserver does not respond to remote `Ctrl-C' interrupts Reply-To: Bug 1031920 <1031920@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 com= munication channel once the debugged process is resumed with "cont". Another way to say that, is that communication with gdb is only possible on= ce 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 inte= rnal 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 some= how 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 th= at 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 -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1031920 Title: Linux user gdbserver does not respond to remote `Ctrl-C' interrupts Status in QEMU: New Bug description: The bug was reproduced 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=3D1, argv=3D0xf6fff24c) at hello.c:5 5 int n =3D 0; (gdb) l 1 #include 2 3 int main (int argc, char **argv) 4 { 5 int n =3D 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1031920/+subscriptions