105 lines
6.4 KiB
HTML
105 lines
6.4 KiB
HTML
|
<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-2019 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>
|
||
|
|
</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">E.10 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>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>’.
|
||
|
|
|
||
|
|
<p>If the stub supports non-stop mode, it should also support the
|
||
|
|
‘<samp><span class="samp">swbreak</span></samp>’ stop reason if software breakpoints are supported, and
|
||
|
|
the ‘<samp><span class="samp">hwbreak</span></samp>’ stop reason if hardware breakpoints are supported
|
||
|
|
(see <a href="swbreak-stop-reason.html#swbreak-stop-reason">swbreak stop reason</a>). This is because given the asynchronous
|
||
|
|
nature of non-stop mode, between the time a thread hits a breakpoint
|
||
|
|
and the time the event is finally processed by <span class="sc">gdb</span>, the
|
||
|
|
breakpoint may have already been removed from the target. Due to
|
||
|
|
this, <span class="sc">gdb</span> needs to be able to tell whether a trap stop was
|
||
|
|
caused by a delayed breakpoint event, which should be ignored, as
|
||
|
|
opposed to a random trap signal, which should be reported to the user.
|
||
|
|
Note the ‘<samp><span class="samp">swbreak</span></samp>’ feature implies that the target is responsible
|
||
|
|
for adjusting the PC when a software breakpoint triggers, if
|
||
|
|
necessary, such as on the x86 architecture.
|
||
|
|
|
||
|
|
</body></html>
|
||
|
|
|