| <html lang="en"> |
| <head> |
| <title>Remote Non-Stop - Debugging with GDB</title> |
| <meta http-equiv="Content-Type" content="text/html"> |
| <meta name="description" content="Debugging with GDB"> |
| <meta name="generator" content="makeinfo 4.13"> |
| <link title="Top" rel="start" href="index.html#Top"> |
| <link rel="up" href="Remote-Protocol.html#Remote-Protocol" title="Remote Protocol"> |
| <link rel="prev" href="Notification-Packets.html#Notification-Packets" title="Notification Packets"> |
| <link rel="next" href="Packet-Acknowledgment.html#Packet-Acknowledgment" title="Packet Acknowledgment"> |
| <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> |
| <!-- |
| Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, |
| 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 |
| Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being ``Free Software'' and ``Free Software Needs |
| Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,'' |
| and with the Back-Cover Texts as in (a) below. |
| |
| (a) The FSF's Back-Cover Text is: ``You are free to copy and modify |
| this GNU Manual. Buying copies from GNU Press supports the FSF in |
| developing GNU and promoting software freedom.''--> |
| <meta http-equiv="Content-Style-Type" content="text/css"> |
| <style type="text/css"><!-- |
| pre.display { font-family:inherit } |
| pre.format { font-family:inherit } |
| pre.smalldisplay { font-family:inherit; font-size:smaller } |
| pre.smallformat { font-family:inherit; font-size:smaller } |
| pre.smallexample { font-size:smaller } |
| pre.smalllisp { font-size:smaller } |
| span.sc { font-variant:small-caps } |
| span.roman { font-family:serif; font-weight:normal; } |
| span.sansserif { font-family:sans-serif; font-weight:normal; } |
| --></style> |
| <link rel="stylesheet" type="text/css" href="../cs.css"> |
| </head> |
| <body> |
| <div class="node"> |
| <a name="Remote-Non-Stop"></a> |
| <a name="Remote-Non_002dStop"></a> |
| <p> |
| Next: <a rel="next" accesskey="n" href="Packet-Acknowledgment.html#Packet-Acknowledgment">Packet Acknowledgment</a>, |
| Previous: <a rel="previous" accesskey="p" href="Notification-Packets.html#Notification-Packets">Notification Packets</a>, |
| Up: <a rel="up" accesskey="u" href="Remote-Protocol.html#Remote-Protocol">Remote Protocol</a> |
| <hr> |
| </div> |
| |
| <h3 class="section">D.11 Remote Protocol Support for Non-Stop Mode</h3> |
| |
| <p><span class="sc">gdb</span>'s remote protocol supports non-stop debugging of |
| multi-threaded programs, as described in <a href="Non_002dStop-Mode.html#Non_002dStop-Mode">Non-Stop Mode</a>. If the stub |
| supports non-stop mode, it should report that to <span class="sc">gdb</span> by including |
| ‘<samp><span class="samp">QNonStop+</span></samp>’ in its ‘<samp><span class="samp">qSupported</span></samp>’ response (see <a href="qSupported.html#qSupported">qSupported</a>). |
| |
| <p><span class="sc">gdb</span> typically sends a ‘<samp><span class="samp">QNonStop</span></samp>’ packet only when |
| establishing a new connection with the stub. Entering non-stop mode |
| does not alter the state of any currently-running threads, but targets |
| must stop all threads in any already-attached processes when entering |
| all-stop mode. <span class="sc">gdb</span> uses the ‘<samp><span class="samp">?</span></samp>’ packet as necessary to |
| probe the target state after a mode change. |
| |
| <p>In non-stop mode, when an attached process encounters an event that |
| would otherwise be reported with a stop reply, it uses the |
| asynchronous notification mechanism (see <a href="Notification-Packets.html#Notification-Packets">Notification Packets</a>) to |
| inform <span class="sc">gdb</span>. In contrast to all-stop mode, where all threads |
| in all processes are stopped when a stop reply is sent, in non-stop |
| mode only the thread reporting the stop event is stopped. That is, |
| when reporting a ‘<samp><span class="samp">S</span></samp>’ or ‘<samp><span class="samp">T</span></samp>’ response to indicate completion |
| of a step operation, hitting a breakpoint, or a fault, only the |
| affected thread is stopped; any other still-running threads continue |
| to run. When reporting a ‘<samp><span class="samp">W</span></samp>’ or ‘<samp><span class="samp">X</span></samp>’ response, all running |
| threads belonging to other attached processes continue to run. |
| |
| <p>Only one stop reply notification at a time may be pending; if |
| additional stop events occur before <span class="sc">gdb</span> has acknowledged the |
| previous notification, they must be queued by the stub for later |
| synchronous transmission in response to ‘<samp><span class="samp">vStopped</span></samp>’ packets from |
| <span class="sc">gdb</span>. Because the notification mechanism is unreliable, |
| the stub is permitted to resend a stop reply notification |
| if it believes <span class="sc">gdb</span> may not have received it. <span class="sc">gdb</span> |
| ignores additional stop reply notifications received before it has |
| finished processing a previous notification and the stub has completed |
| sending any queued stop events. |
| |
| <p>Otherwise, <span class="sc">gdb</span> must be prepared to receive a stop reply |
| notification at any time. Specifically, they may appear when |
| <span class="sc">gdb</span> is not otherwise reading input from the stub, or when |
| <span class="sc">gdb</span> is expecting to read a normal synchronous response or a |
| ‘<samp><span class="samp">+</span></samp>’/‘<samp><span class="samp">-</span></samp>’ acknowledgment to a packet it has sent. |
| Notification packets are distinct from any other communication from |
| the stub so there is no ambiguity. |
| |
| <p>After receiving a stop reply notification, <span class="sc">gdb</span> shall |
| acknowledge it by sending a ‘<samp><span class="samp">vStopped</span></samp>’ packet (see <a href="vStopped-packet.html#vStopped-packet">vStopped packet</a>) |
| as a regular, synchronous request to the stub. Such acknowledgment |
| is not required to happen immediately, as <span class="sc">gdb</span> is permitted to |
| send other, unrelated packets to the stub first, which the stub should |
| process normally. |
| |
| <p>Upon receiving a ‘<samp><span class="samp">vStopped</span></samp>’ packet, if the stub has other queued |
| stop events to report to <span class="sc">gdb</span>, it shall respond by sending a |
| normal stop reply response. <span class="sc">gdb</span> shall then send another |
| ‘<samp><span class="samp">vStopped</span></samp>’ packet to solicit further responses; again, it is |
| permitted to send other, unrelated packets as well which the stub |
| should process normally. |
| |
| <p>If the stub receives a ‘<samp><span class="samp">vStopped</span></samp>’ packet and there are no |
| additional stop events to report, the stub shall return an ‘<samp><span class="samp">OK</span></samp>’ |
| response. At this point, if further stop events occur, the stub shall |
| send a new stop reply notification, <span class="sc">gdb</span> shall accept the |
| notification, and the process shall be repeated. |
| |
| <p>In non-stop mode, the target shall respond to the ‘<samp><span class="samp">?</span></samp>’ packet as |
| follows. First, any incomplete stop reply notification/‘<samp><span class="samp">vStopped</span></samp>’ |
| sequence in progress is abandoned. The target must begin a new |
| sequence reporting stop events for all stopped threads, whether or not |
| it has previously reported those events to <span class="sc">gdb</span>. The first |
| stop reply is sent as a synchronous reply to the ‘<samp><span class="samp">?</span></samp>’ packet, and |
| subsequent stop replies are sent as responses to ‘<samp><span class="samp">vStopped</span></samp>’ packets |
| using the mechanism described above. The target must not send |
| asynchronous stop reply notifications until the sequence is complete. |
| If all threads are running when the target receives the ‘<samp><span class="samp">?</span></samp>’ packet, |
| or if the target is not attached to any process, it shall respond |
| ‘<samp><span class="samp">OK</span></samp>’. |
| |
| </body></html> |
| |
