• Home
  • History
  • Annotate
  • Line#
  • Navigate
  • Raw
  • Download
  • only in /asuswrt-rt-n18u-9.0.0.4.380.2695/release/src-rt-6.x.4708/toolchains/hndtools-armeabi-2011.09/share/doc/arm-arm-none-eabi/html/gdb/
1<html lang="en">
2<head>
3<title>Remote Non-Stop - Debugging with GDB</title>
4<meta http-equiv="Content-Type" content="text/html">
5<meta name="description" content="Debugging with GDB">
6<meta name="generator" content="makeinfo 4.13">
7<link title="Top" rel="start" href="index.html#Top">
8<link rel="up" href="Remote-Protocol.html#Remote-Protocol" title="Remote Protocol">
9<link rel="prev" href="Notification-Packets.html#Notification-Packets" title="Notification Packets">
10<link rel="next" href="Packet-Acknowledgment.html#Packet-Acknowledgment" title="Packet Acknowledgment">
11<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
12<!--
13Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,
141998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
15Free Software Foundation, Inc.
16
17Permission is granted to copy, distribute and/or modify this document
18under the terms of the GNU Free Documentation License, Version 1.3 or
19any later version published by the Free Software Foundation; with the
20Invariant Sections being ``Free Software'' and ``Free Software Needs
21Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,''
22and with the Back-Cover Texts as in (a) below.
23
24(a) The FSF's Back-Cover Text is: ``You are free to copy and modify
25this GNU Manual.  Buying copies from GNU Press supports the FSF in
26developing GNU and promoting software freedom.''-->
27<meta http-equiv="Content-Style-Type" content="text/css">
28<style type="text/css"><!--
29  pre.display { font-family:inherit }
30  pre.format  { font-family:inherit }
31  pre.smalldisplay { font-family:inherit; font-size:smaller }
32  pre.smallformat  { font-family:inherit; font-size:smaller }
33  pre.smallexample { font-size:smaller }
34  pre.smalllisp    { font-size:smaller }
35  span.sc    { font-variant:small-caps }
36  span.roman { font-family:serif; font-weight:normal; } 
37  span.sansserif { font-family:sans-serif; font-weight:normal; } 
38--></style>
39<link rel="stylesheet" type="text/css" href="../cs.css">
40</head>
41<body>
42<div class="node">
43<a name="Remote-Non-Stop"></a>
44<a name="Remote-Non_002dStop"></a>
45<p>
46Next:&nbsp;<a rel="next" accesskey="n" href="Packet-Acknowledgment.html#Packet-Acknowledgment">Packet Acknowledgment</a>,
47Previous:&nbsp;<a rel="previous" accesskey="p" href="Notification-Packets.html#Notification-Packets">Notification Packets</a>,
48Up:&nbsp;<a rel="up" accesskey="u" href="Remote-Protocol.html#Remote-Protocol">Remote Protocol</a>
49<hr>
50</div>
51
52<h3 class="section">D.11 Remote Protocol Support for Non-Stop Mode</h3>
53
54<p><span class="sc">gdb</span>'s remote protocol supports non-stop debugging of
55multi-threaded programs, as described in <a href="Non_002dStop-Mode.html#Non_002dStop-Mode">Non-Stop Mode</a>.  If the stub
56supports non-stop mode, it should report that to <span class="sc">gdb</span> by including
57&lsquo;<samp><span class="samp">QNonStop+</span></samp>&rsquo; in its &lsquo;<samp><span class="samp">qSupported</span></samp>&rsquo; response (see <a href="qSupported.html#qSupported">qSupported</a>).
58
59   <p><span class="sc">gdb</span> typically sends a &lsquo;<samp><span class="samp">QNonStop</span></samp>&rsquo; packet only when
60establishing a new connection with the stub.  Entering non-stop mode
61does not alter the state of any currently-running threads, but targets
62must stop all threads in any already-attached processes when entering
63all-stop mode.  <span class="sc">gdb</span> uses the &lsquo;<samp><span class="samp">?</span></samp>&rsquo; packet as necessary to
64probe the target state after a mode change.
65
66   <p>In non-stop mode, when an attached process encounters an event that
67would otherwise be reported with a stop reply, it uses the
68asynchronous notification mechanism (see <a href="Notification-Packets.html#Notification-Packets">Notification Packets</a>) to
69inform <span class="sc">gdb</span>.  In contrast to all-stop mode, where all threads
70in all processes are stopped when a stop reply is sent, in non-stop
71mode only the thread reporting the stop event is stopped.  That is,
72when reporting a &lsquo;<samp><span class="samp">S</span></samp>&rsquo; or &lsquo;<samp><span class="samp">T</span></samp>&rsquo; response to indicate completion
73of a step operation, hitting a breakpoint, or a fault, only the
74affected thread is stopped; any other still-running threads continue
75to run.  When reporting a &lsquo;<samp><span class="samp">W</span></samp>&rsquo; or &lsquo;<samp><span class="samp">X</span></samp>&rsquo; response, all running
76threads belonging to other attached processes continue to run.
77
78   <p>Only one stop reply notification at a time may be pending; if
79additional stop events occur before <span class="sc">gdb</span> has acknowledged the
80previous notification, they must be queued by the stub for later
81synchronous transmission in response to &lsquo;<samp><span class="samp">vStopped</span></samp>&rsquo; packets from
82<span class="sc">gdb</span>.  Because the notification mechanism is unreliable,
83the stub is permitted to resend a stop reply notification
84if it believes <span class="sc">gdb</span> may not have received it.  <span class="sc">gdb</span>
85ignores additional stop reply notifications received before it has
86finished processing a previous notification and the stub has completed
87sending any queued stop events.
88
89   <p>Otherwise, <span class="sc">gdb</span> must be prepared to receive a stop reply
90notification at any time.  Specifically, they may appear when
91<span class="sc">gdb</span> is not otherwise reading input from the stub, or when
92<span class="sc">gdb</span> is expecting to read a normal synchronous response or a
93&lsquo;<samp><span class="samp">+</span></samp>&rsquo;/&lsquo;<samp><span class="samp">-</span></samp>&rsquo; acknowledgment to a packet it has sent. 
94Notification packets are distinct from any other communication from
95the stub so there is no ambiguity.
96
97   <p>After receiving a stop reply notification, <span class="sc">gdb</span> shall
98acknowledge it by sending a &lsquo;<samp><span class="samp">vStopped</span></samp>&rsquo; packet (see <a href="vStopped-packet.html#vStopped-packet">vStopped packet</a>)
99as a regular, synchronous request to the stub.  Such acknowledgment
100is not required to happen immediately, as <span class="sc">gdb</span> is permitted to
101send other, unrelated packets to the stub first, which the stub should
102process normally.
103
104   <p>Upon receiving a &lsquo;<samp><span class="samp">vStopped</span></samp>&rsquo; packet, if the stub has other queued
105stop events to report to <span class="sc">gdb</span>, it shall respond by sending a
106normal stop reply response.  <span class="sc">gdb</span> shall then send another
107&lsquo;<samp><span class="samp">vStopped</span></samp>&rsquo; packet to solicit further responses; again, it is
108permitted to send other, unrelated packets as well which the stub
109should process normally.
110
111   <p>If the stub receives a &lsquo;<samp><span class="samp">vStopped</span></samp>&rsquo; packet and there are no
112additional stop events to report, the stub shall return an &lsquo;<samp><span class="samp">OK</span></samp>&rsquo;
113response.  At this point, if further stop events occur, the stub shall
114send a new stop reply notification, <span class="sc">gdb</span> shall accept the
115notification, and the process shall be repeated.
116
117   <p>In non-stop mode, the target shall respond to the &lsquo;<samp><span class="samp">?</span></samp>&rsquo; packet as
118follows.  First, any incomplete stop reply notification/&lsquo;<samp><span class="samp">vStopped</span></samp>&rsquo;
119sequence in progress is abandoned.  The target must begin a new
120sequence reporting stop events for all stopped threads, whether or not
121it has previously reported those events to <span class="sc">gdb</span>.  The first
122stop reply is sent as a synchronous reply to the &lsquo;<samp><span class="samp">?</span></samp>&rsquo; packet, and
123subsequent stop replies are sent as responses to &lsquo;<samp><span class="samp">vStopped</span></samp>&rsquo; packets
124using the mechanism described above.  The target must not send
125asynchronous stop reply notifications until the sequence is complete. 
126If all threads are running when the target receives the &lsquo;<samp><span class="samp">?</span></samp>&rsquo; packet,
127or if the target is not attached to any process, it shall respond
128&lsquo;<samp><span class="samp">OK</span></samp>&rsquo;.
129
130   </body></html>
131
132