| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
| <html> |
| <!-- Copyright (C) 1988-2015 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." --> |
| <!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ --> |
| <head> |
| <title>Debugging with GDB: Packets</title> |
| |
| <meta name="description" content="Debugging with GDB: Packets"> |
| <meta name="keywords" content="Debugging with GDB: Packets"> |
| <meta name="resource-type" content="document"> |
| <meta name="distribution" content="global"> |
| <meta name="Generator" content="makeinfo"> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| <link href="index.html#Top" rel="start" title="Top"> |
| <link href="Concept-Index.html#Concept-Index" rel="index" title="Concept Index"> |
| <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents"> |
| <link href="Remote-Protocol.html#Remote-Protocol" rel="up" title="Remote Protocol"> |
| <link href="Stop-Reply-Packets.html#Stop-Reply-Packets" rel="next" title="Stop Reply Packets"> |
| <link href="Overview.html#Overview" rel="prev" title="Overview"> |
| <style type="text/css"> |
| <!-- |
| a.summary-letter {text-decoration: none} |
| blockquote.smallquotation {font-size: smaller} |
| div.display {margin-left: 3.2em} |
| div.example {margin-left: 3.2em} |
| div.indentedblock {margin-left: 3.2em} |
| div.lisp {margin-left: 3.2em} |
| div.smalldisplay {margin-left: 3.2em} |
| div.smallexample {margin-left: 3.2em} |
| div.smallindentedblock {margin-left: 3.2em; font-size: smaller} |
| div.smalllisp {margin-left: 3.2em} |
| kbd {font-style:oblique} |
| pre.display {font-family: inherit} |
| pre.format {font-family: inherit} |
| pre.menu-comment {font-family: serif} |
| pre.menu-preformatted {font-family: serif} |
| pre.smalldisplay {font-family: inherit; font-size: smaller} |
| pre.smallexample {font-size: smaller} |
| pre.smallformat {font-family: inherit; font-size: smaller} |
| pre.smalllisp {font-size: smaller} |
| span.nocodebreak {white-space:nowrap} |
| span.nolinebreak {white-space:nowrap} |
| span.roman {font-family:serif; font-weight:normal} |
| span.sansserif {font-family:sans-serif; font-weight:normal} |
| ul.no-bullet {list-style: none} |
| --> |
| </style> |
| |
| |
| </head> |
| |
| <body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> |
| <a name="Packets"></a> |
| <div class="header"> |
| <p> |
| Next: <a href="Stop-Reply-Packets.html#Stop-Reply-Packets" accesskey="n" rel="next">Stop Reply Packets</a>, Previous: <a href="Overview.html#Overview" accesskey="p" rel="prev">Overview</a>, Up: <a href="Remote-Protocol.html#Remote-Protocol" accesskey="u" rel="up">Remote Protocol</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p> |
| </div> |
| <hr> |
| <a name="Packets-1"></a> |
| <h3 class="section">E.2 Packets</h3> |
| |
| <p>The following table provides a complete list of all currently defined |
| <var>command</var>s and their corresponding response <var>data</var>. |
| See <a href="File_002dI_002fO-Remote-Protocol-Extension.html#File_002dI_002fO-Remote-Protocol-Extension">File-I/O Remote Protocol Extension</a>, for details about the File |
| I/O extension of the remote protocol. |
| </p> |
| <p>Each packet’s description has a template showing the packet’s overall |
| syntax, followed by an explanation of the packet’s meaning. We |
| include spaces in some of the templates for clarity; these are not |
| part of the packet’s syntax. No <small>GDB</small> packet uses spaces to |
| separate its components. For example, a template like ‘<samp>foo |
| <var>bar</var> <var>baz</var></samp>’ describes a packet beginning with the three ASCII |
| bytes ‘<samp>foo</samp>’, followed by a <var>bar</var>, followed directly by a |
| <var>baz</var>. <small>GDB</small> does not transmit a space character between the |
| ‘<samp>foo</samp>’ and the <var>bar</var>, or between the <var>bar</var> and the |
| <var>baz</var>. |
| </p> |
| <a name="index-thread_002did_002c-in-remote-protocol"></a> |
| <a name="thread_002did-syntax"></a><p>Several packets and replies include a <var>thread-id</var> field to identify |
| a thread. Normally these are positive numbers with a target-specific |
| interpretation, formatted as big-endian hex strings. A <var>thread-id</var> |
| can also be a literal ‘<samp>-1</samp>’ to indicate all threads, or ‘<samp>0</samp>’ to |
| pick any thread. |
| </p> |
| <p>In addition, the remote protocol supports a multiprocess feature in |
| which the <var>thread-id</var> syntax is extended to optionally include both |
| process and thread ID fields, as ‘<samp>p<var>pid</var>.<var>tid</var></samp>’. |
| The <var>pid</var> (process) and <var>tid</var> (thread) components each have the |
| format described above: a positive number with target-specific |
| interpretation formatted as a big-endian hex string, literal ‘<samp>-1</samp>’ |
| to indicate all processes or threads (respectively), or ‘<samp>0</samp>’ to |
| indicate an arbitrary process or thread. Specifying just a process, as |
| ‘<samp>p<var>pid</var></samp>’, is equivalent to ‘<samp>p<var>pid</var>.-1</samp>’. It is an |
| error to specify all processes but a specific thread, such as |
| ‘<samp>p-1.<var>tid</var></samp>’. Note that the ‘<samp>p</samp>’ prefix is <em>not</em> used |
| for those packets and replies explicitly documented to include a process |
| ID, rather than a <var>thread-id</var>. |
| </p> |
| <p>The multiprocess <var>thread-id</var> syntax extensions are only used if both |
| <small>GDB</small> and the stub report support for the ‘<samp>multiprocess</samp>’ |
| feature using ‘<samp>qSupported</samp>’. See <a href="General-Query-Packets.html#multiprocess-extensions">multiprocess extensions</a>, for |
| more information. |
| </p> |
| <p>Note that all packet forms beginning with an upper- or lower-case |
| letter, other than those described here, are reserved for future use. |
| </p> |
| <p>Here are the packet descriptions. |
| </p> |
| <dl compact="compact"> |
| <dt>‘<samp>!</samp>’</dt> |
| <dd><a name="index-_0021-packet"></a> |
| <a name="extended-mode"></a><p>Enable extended mode. In extended mode, the remote server is made |
| persistent. The ‘<samp>R</samp>’ packet is used to restart the program being |
| debugged. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>The remote target both supports and has enabled extended mode. |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>?</samp>’</dt> |
| <dd><a name="index-_003f-packet"></a> |
| <a name="g_t_003f-packet"></a><p>Indicate the reason the target halted. The reply is the same as for |
| step and continue. This packet has a special interpretation when the |
| target is in non-stop mode; see <a href="Remote-Non_002dStop.html#Remote-Non_002dStop">Remote Non-Stop</a>. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| </dd> |
| <dt>‘<samp>A <var>arglen</var>,<var>argnum</var>,<var>arg</var>,…</samp>’</dt> |
| <dd><a name="index-A-packet"></a> |
| <p>Initialized <code>argv[]</code> array passed into program. <var>arglen</var> |
| specifies the number of bytes in the hex encoded byte stream |
| <var>arg</var>. See <code>gdbserver</code> for more details. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>The arguments were set. |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>An error occurred. |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>b <var>baud</var></samp>’</dt> |
| <dd><a name="index-b-packet"></a> |
| <p>(Don’t use this packet; its behavior is not well-defined.) |
| Change the serial line speed to <var>baud</var>. |
| </p> |
| <p>JTC: <em>When does the transport layer state change? When it’s |
| received, or after the ACK is transmitted. In either case, there are |
| problems if the command or the acknowledgment packet is dropped.</em> |
| </p> |
| <p>Stan: <em>If people really wanted to add something like this, and get |
| it working for the first time, they ought to modify ser-unix.c to send |
| some kind of out-of-band message to a specially-setup stub and have the |
| switch happen "in between" packets, so that from remote protocol’s point |
| of view, nothing actually happened.</em> |
| </p> |
| </dd> |
| <dt>‘<samp>B <var>addr</var>,<var>mode</var></samp>’</dt> |
| <dd><a name="index-B-packet"></a> |
| <p>Set (<var>mode</var> is ‘<samp>S</samp>’) or clear (<var>mode</var> is ‘<samp>C</samp>’) a |
| breakpoint at <var>addr</var>. |
| </p> |
| <p>Don’t use this packet. Use the ‘<samp>Z</samp>’ and ‘<samp>z</samp>’ packets instead |
| (see <a href="#insert-breakpoint-or-watchpoint-packet">insert breakpoint or watchpoint packet</a>). |
| </p> |
| <a name="index-bc-packet"></a> |
| <a name="bc"></a></dd> |
| <dt>‘<samp>bc</samp>’</dt> |
| <dd><p>Backward continue. Execute the target system in reverse. No parameter. |
| See <a href="Reverse-Execution.html#Reverse-Execution">Reverse Execution</a>, for more information. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| <a name="index-bs-packet"></a> |
| <a name="bs"></a></dd> |
| <dt>‘<samp>bs</samp>’</dt> |
| <dd><p>Backward single step. Execute one instruction in reverse. No parameter. |
| See <a href="Reverse-Execution.html#Reverse-Execution">Reverse Execution</a>, for more information. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| </dd> |
| <dt>‘<samp>c <span class="roman">[</span><var>addr</var><span class="roman">]</span></samp>’</dt> |
| <dd><a name="index-c-packet"></a> |
| <p>Continue at <var>addr</var>, which is the address to resume. If <var>addr</var> |
| is omitted, resume at current address. |
| </p> |
| <p>This packet is deprecated for multi-threading support. See <a href="#vCont-packet">vCont packet</a>. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| </dd> |
| <dt>‘<samp>C <var>sig</var><span class="roman">[</span>;<var>addr</var><span class="roman">]</span></samp>’</dt> |
| <dd><a name="index-C-packet"></a> |
| <p>Continue with signal <var>sig</var> (hex signal number). If |
| ‘<samp>;<var>addr</var></samp>’ is omitted, resume at same address. |
| </p> |
| <p>This packet is deprecated for multi-threading support. See <a href="#vCont-packet">vCont packet</a>. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| </dd> |
| <dt>‘<samp>d</samp>’</dt> |
| <dd><a name="index-d-packet"></a> |
| <p>Toggle debug flag. |
| </p> |
| <p>Don’t use this packet; instead, define a general set packet |
| (see <a href="General-Query-Packets.html#General-Query-Packets">General Query Packets</a>). |
| </p> |
| </dd> |
| <dt>‘<samp>D</samp>’</dt> |
| <dt>‘<samp>D;<var>pid</var></samp>’</dt> |
| <dd><a name="index-D-packet"></a> |
| <p>The first form of the packet is used to detach <small>GDB</small> from the |
| remote system. It is sent to the remote target |
| before <small>GDB</small> disconnects via the <code>detach</code> command. |
| </p> |
| <p>The second form, including a process ID, is used when multiprocess |
| protocol extensions are enabled (see <a href="General-Query-Packets.html#multiprocess-extensions">multiprocess extensions</a>), to |
| detach only a specific process. The <var>pid</var> is specified as a |
| big-endian hex string. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>F <var>RC</var>,<var>EE</var>,<var>CF</var>;<var>XX</var></samp>’</dt> |
| <dd><a name="index-F-packet"></a> |
| <p>A reply from <small>GDB</small> to an ‘<samp>F</samp>’ packet sent by the target. |
| This is part of the File-I/O protocol extension. See <a href="File_002dI_002fO-Remote-Protocol-Extension.html#File_002dI_002fO-Remote-Protocol-Extension">File-I/O Remote Protocol Extension</a>, for the specification. |
| </p> |
| </dd> |
| <dt>‘<samp>g</samp>’</dt> |
| <dd><a name="read-registers-packet"></a><a name="index-g-packet"></a> |
| <p>Read general registers. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp><var>XX…</var></samp>’</dt> |
| <dd><p>Each byte of register data is described by two hex digits. The bytes |
| with the register are transmitted in target byte order. The size of |
| each register and their position within the ‘<samp>g</samp>’ packet are |
| determined by the <small>GDB</small> internal gdbarch functions |
| <code>DEPRECATED_REGISTER_RAW_SIZE</code> and <code>gdbarch_register_name</code>. The |
| specification of several standard ‘<samp>g</samp>’ packets is specified below. |
| </p> |
| <p>When reading registers from a trace frame (see <a href="Analyze-Collected-Data.html#Analyze-Collected-Data">Using the Collected Data</a>), the stub may also return a string of |
| literal ‘<samp>x</samp>’’s in place of the register data digits, to indicate |
| that the corresponding register has not been collected, thus its value |
| is unavailable. For example, for an architecture with 4 registers of |
| 4 bytes each, the following reply indicates to <small>GDB</small> that |
| registers 0 and 2 have not been collected, while registers 1 and 3 |
| have been collected, and both have zero value: |
| </p> |
| <div class="smallexample"> |
| <pre class="smallexample">-> <code>g</code> |
| <- <code>xxxxxxxx00000000xxxxxxxx00000000</code> |
| </pre></div> |
| |
| </dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error. |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>G <var>XX…</var></samp>’</dt> |
| <dd><a name="index-G-packet"></a> |
| <p>Write general registers. See <a href="#read-registers-packet">read registers packet</a>, for a |
| description of the <var>XX…</var> data. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>H <var>op</var> <var>thread-id</var></samp>’</dt> |
| <dd><a name="index-H-packet"></a> |
| <p>Set thread for subsequent operations (‘<samp>m</samp>’, ‘<samp>M</samp>’, ‘<samp>g</samp>’, |
| ‘<samp>G</samp>’, et.al.). Depending on the operation to be performed, <var>op</var> |
| should be ‘<samp>c</samp>’ for step and continue operations (note that this |
| is deprecated, supporting the ‘<samp>vCont</samp>’ command is a better |
| option), and ‘<samp>g</samp>’ for other operations. The thread designator |
| <var>thread-id</var> has the format and interpretation described in |
| <a href="#thread_002did-syntax">thread-id syntax</a>. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| |
| </dd> |
| <dt>‘<samp>i <span class="roman">[</span><var>addr</var><span class="roman">[</span>,<var>nnn</var><span class="roman">]]</span></samp>’</dt> |
| <dd><a name="cycle-step-packet"></a><a name="index-i-packet"></a> |
| <p>Step the remote target by a single clock cycle. If ‘<samp>,<var>nnn</var></samp>’ is |
| present, cycle step <var>nnn</var> cycles. If <var>addr</var> is present, cycle |
| step starting at that address. |
| </p> |
| </dd> |
| <dt>‘<samp>I</samp>’</dt> |
| <dd><a name="index-I-packet"></a> |
| <p>Signal, then cycle step. See <a href="#step-with-signal-packet">step with signal packet</a>. See <a href="#cycle-step-packet">cycle step packet</a>. |
| </p> |
| </dd> |
| <dt>‘<samp>k</samp>’</dt> |
| <dd><a name="index-k-packet"></a> |
| <p>Kill request. |
| </p> |
| <p>The exact effect of this packet is not specified. |
| </p> |
| <p>For a bare-metal target, it may power cycle or reset the target |
| system. For that reason, the ‘<samp>k</samp>’ packet has no reply. |
| </p> |
| <p>For a single-process target, it may kill that process if possible. |
| </p> |
| <p>A multiple-process target may choose to kill just one process, or all |
| that are under <small>GDB</small>’s control. For more precise control, use |
| the vKill packet (see <a href="#vKill-packet">vKill packet</a>). |
| </p> |
| <p>If the target system immediately closes the connection in response to |
| ‘<samp>k</samp>’, <small>GDB</small> does not consider the lack of packet |
| acknowledgment to be an error, and assumes the kill was successful. |
| </p> |
| <p>If connected using <kbd>target extended-remote</kbd>, and the target does |
| not close the connection in response to a kill request, <small>GDB</small> |
| probes the target state as if a new connection was opened |
| (see <a href="#g_t_003f-packet">? packet</a>). |
| </p> |
| </dd> |
| <dt>‘<samp>m <var>addr</var>,<var>length</var></samp>’</dt> |
| <dd><a name="index-m-packet"></a> |
| <p>Read <var>length</var> addressable memory units starting at address <var>addr</var> |
| (see <a href="Memory.html#addressable-memory-unit">addressable memory unit</a>). Note that <var>addr</var> may not be aligned to |
| any particular boundary. |
| </p> |
| <p>The stub need not use any particular size or alignment when gathering |
| data from memory for the response; even if <var>addr</var> is word-aligned |
| and <var>length</var> is a multiple of the word size, the stub is free to |
| use byte accesses, or not. For this reason, this packet may not be |
| suitable for accessing memory-mapped I/O devices. |
| <a name="index-alignment-of-remote-memory-accesses"></a> |
| <a name="index-size-of-remote-memory-accesses"></a> |
| <a name="index-memory_002c-alignment-and-size-of-remote-accesses"></a> |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp><var>XX…</var></samp>’</dt> |
| <dd><p>Memory contents; each byte is transmitted as a two-digit hexadecimal number. |
| The reply may contain fewer addressable memory units than requested if the |
| server was able to read only part of the region of memory. |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p><var>NN</var> is errno |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>M <var>addr</var>,<var>length</var>:<var>XX…</var></samp>’</dt> |
| <dd><a name="index-M-packet"></a> |
| <p>Write <var>length</var> addressable memory units starting at address <var>addr</var> |
| (see <a href="Memory.html#addressable-memory-unit">addressable memory unit</a>). The data is given by <var>XX…</var>; each |
| byte is transmitted as a two-digit hexadecimal number. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error (this includes the case where only part of the data was |
| written). |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>p <var>n</var></samp>’</dt> |
| <dd><a name="index-p-packet"></a> |
| <p>Read the value of register <var>n</var>; <var>n</var> is in hex. |
| See <a href="#read-registers-packet">read registers packet</a>, for a description of how the returned |
| register value is encoded. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp><var>XX…</var></samp>’</dt> |
| <dd><p>the register’s value |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| <dt>‘<samp><!-- /@w --></samp>’</dt> |
| <dd><p>Indicating an unrecognized <var>query</var>. |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>P <var>n…</var>=<var>r…</var></samp>’</dt> |
| <dd><a name="write-register-packet"></a><a name="index-P-packet"></a> |
| <p>Write register <var>n…</var> with value <var>r…</var>. The register |
| number <var>n</var> is in hexadecimal, and <var>r…</var> contains two hex |
| digits for each byte in the register (target byte order). |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>q <var>name</var> <var>params</var>…</samp>’</dt> |
| <dt>‘<samp>Q <var>name</var> <var>params</var>…</samp>’</dt> |
| <dd><a name="index-q-packet"></a> |
| <a name="index-Q-packet"></a> |
| <p>General query (‘<samp>q</samp>’) and set (‘<samp>Q</samp>’). These packets are |
| described fully in <a href="General-Query-Packets.html#General-Query-Packets">General Query Packets</a>. |
| </p> |
| </dd> |
| <dt>‘<samp>r</samp>’</dt> |
| <dd><a name="index-r-packet"></a> |
| <p>Reset the entire system. |
| </p> |
| <p>Don’t use this packet; use the ‘<samp>R</samp>’ packet instead. |
| </p> |
| </dd> |
| <dt>‘<samp>R <var>XX</var></samp>’</dt> |
| <dd><a name="index-R-packet"></a> |
| <p>Restart the program being debugged. The <var>XX</var>, while needed, is ignored. |
| This packet is only available in extended mode (see <a href="#extended-mode">extended mode</a>). |
| </p> |
| <p>The ‘<samp>R</samp>’ packet has no reply. |
| </p> |
| </dd> |
| <dt>‘<samp>s <span class="roman">[</span><var>addr</var><span class="roman">]</span></samp>’</dt> |
| <dd><a name="index-s-packet"></a> |
| <p>Single step, resuming at <var>addr</var>. If |
| <var>addr</var> is omitted, resume at same address. |
| </p> |
| <p>This packet is deprecated for multi-threading support. See <a href="#vCont-packet">vCont packet</a>. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| </dd> |
| <dt>‘<samp>S <var>sig</var><span class="roman">[</span>;<var>addr</var><span class="roman">]</span></samp>’</dt> |
| <dd><a name="step-with-signal-packet"></a><a name="index-S-packet"></a> |
| <p>Step with signal. This is analogous to the ‘<samp>C</samp>’ packet, but |
| requests a single-step, rather than a normal resumption of execution. |
| </p> |
| <p>This packet is deprecated for multi-threading support. See <a href="#vCont-packet">vCont packet</a>. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| </dd> |
| <dt>‘<samp>t <var>addr</var>:<var>PP</var>,<var>MM</var></samp>’</dt> |
| <dd><a name="index-t-packet"></a> |
| <p>Search backwards starting at address <var>addr</var> for a match with pattern |
| <var>PP</var> and mask <var>MM</var>, both of which are are 4 byte long. |
| There must be at least 3 digits in <var>addr</var>. |
| </p> |
| </dd> |
| <dt>‘<samp>T <var>thread-id</var></samp>’</dt> |
| <dd><a name="index-T-packet"></a> |
| <p>Find out if the thread <var>thread-id</var> is alive. See <a href="#thread_002did-syntax">thread-id syntax</a>. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>thread is still alive |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>thread is dead |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>v</samp>’</dt> |
| <dd><p>Packets starting with ‘<samp>v</samp>’ are identified by a multi-letter name, |
| up to the first ‘<samp>;</samp>’ or ‘<samp>?</samp>’ (or the end of the packet). |
| </p> |
| </dd> |
| <dt>‘<samp>vAttach;<var>pid</var></samp>’</dt> |
| <dd><a name="index-vAttach-packet"></a> |
| <p>Attach to a new process with the specified process ID <var>pid</var>. |
| The process ID is a |
| hexadecimal integer identifying the process. In all-stop mode, all |
| threads in the attached process are stopped; in non-stop mode, it may be |
| attached without being stopped if that is supported by the target. |
| </p> |
| |
| <p>This packet is only available in extended mode (see <a href="#extended-mode">extended mode</a>). |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>E <var>nn</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| <dt>‘<samp><span class="roman">Any stop packet</span></samp>’</dt> |
| <dd><p>for success in all-stop mode (see <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>) |
| </p></dd> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success in non-stop mode (see <a href="Remote-Non_002dStop.html#Remote-Non_002dStop">Remote Non-Stop</a>) |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>vCont<span class="roman">[</span>;<var>action</var><span class="roman">[</span>:<var>thread-id</var><span class="roman">]]</span>…</samp>’</dt> |
| <dd><a name="index-vCont-packet"></a> |
| <a name="vCont-packet"></a><p>Resume the inferior, specifying different actions for each thread. |
| If an action is specified with no <var>thread-id</var>, then it is applied to any |
| threads that don’t have a specific action specified; if no default action is |
| specified then other threads should remain stopped in all-stop mode and |
| in their current state in non-stop mode. |
| Specifying multiple |
| default actions is an error; specifying no actions is also an error. |
| Thread IDs are specified using the syntax described in <a href="#thread_002did-syntax">thread-id syntax</a>. |
| </p> |
| <p>Currently supported actions are: |
| </p> |
| <dl compact="compact"> |
| <dt>‘<samp>c</samp>’</dt> |
| <dd><p>Continue. |
| </p></dd> |
| <dt>‘<samp>C <var>sig</var></samp>’</dt> |
| <dd><p>Continue with signal <var>sig</var>. The signal <var>sig</var> should be two hex digits. |
| </p></dd> |
| <dt>‘<samp>s</samp>’</dt> |
| <dd><p>Step. |
| </p></dd> |
| <dt>‘<samp>S <var>sig</var></samp>’</dt> |
| <dd><p>Step with signal <var>sig</var>. The signal <var>sig</var> should be two hex digits. |
| </p></dd> |
| <dt>‘<samp>t</samp>’</dt> |
| <dd><p>Stop. |
| </p></dd> |
| <dt>‘<samp>r <var>start</var>,<var>end</var></samp>’</dt> |
| <dd><p>Step once, and then keep stepping as long as the thread stops at |
| addresses between <var>start</var> (inclusive) and <var>end</var> (exclusive). |
| The remote stub reports a stop reply when either the thread goes out |
| of the range or is stopped due to an unrelated reason, such as hitting |
| a breakpoint. See <a href="Continuing-and-Stepping.html#range-stepping">range stepping</a>. |
| </p> |
| <p>If the range is empty (<var>start</var> == <var>end</var>), then the action |
| becomes equivalent to the ‘<samp>s</samp>’ action. In other words, |
| single-step once, and report the stop (even if the stepped instruction |
| jumps to <var>start</var>). |
| </p> |
| <p>(A stop reply may be sent at any point even if the PC is still within |
| the stepping range; for example, it is valid to implement this packet |
| in a degenerate way as a single instruction step operation.) |
| </p> |
| </dd> |
| </dl> |
| |
| <p>The optional argument <var>addr</var> normally associated with the |
| ‘<samp>c</samp>’, ‘<samp>C</samp>’, ‘<samp>s</samp>’, and ‘<samp>S</samp>’ packets is |
| not supported in ‘<samp>vCont</samp>’. |
| </p> |
| <p>The ‘<samp>t</samp>’ action is only relevant in non-stop mode |
| (see <a href="Remote-Non_002dStop.html#Remote-Non_002dStop">Remote Non-Stop</a>) and may be ignored by the stub otherwise. |
| A stop reply should be generated for any affected thread not already stopped. |
| When a thread is stopped by means of a ‘<samp>t</samp>’ action, |
| the corresponding stop reply should indicate that the thread has stopped with |
| signal ‘<samp>0</samp>’, regardless of whether the target uses some other signal |
| as an implementation detail. |
| </p> |
| <p>The stub must support ‘<samp>vCont</samp>’ if it reports support for |
| multiprocess extensions (see <a href="General-Query-Packets.html#multiprocess-extensions">multiprocess extensions</a>). Note that in |
| this case ‘<samp>vCont</samp>’ actions can be specified to apply to all threads |
| in a process by using the ‘<samp>p<var>pid</var>.-1</samp>’ form of the |
| <var>thread-id</var>. |
| </p> |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| </p> |
| </dd> |
| <dt>‘<samp>vCont?</samp>’</dt> |
| <dd><a name="index-vCont_003f-packet"></a> |
| <p>Request a list of actions supported by the ‘<samp>vCont</samp>’ packet. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>vCont<span class="roman">[</span>;<var>action</var>…<span class="roman">]</span></samp>’</dt> |
| <dd><p>The ‘<samp>vCont</samp>’ packet is supported. Each <var>action</var> is a supported |
| command in the ‘<samp>vCont</samp>’ packet. |
| </p></dd> |
| <dt>‘<samp><!-- /@w --></samp>’</dt> |
| <dd><p>The ‘<samp>vCont</samp>’ packet is not supported. |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>vFile:<var>operation</var>:<var>parameter</var>…</samp>’</dt> |
| <dd><a name="index-vFile-packet"></a> |
| <p>Perform a file operation on the target system. For details, |
| see <a href="Host-I_002fO-Packets.html#Host-I_002fO-Packets">Host I/O Packets</a>. |
| </p> |
| </dd> |
| <dt>‘<samp>vFlashErase:<var>addr</var>,<var>length</var></samp>’</dt> |
| <dd><a name="index-vFlashErase-packet"></a> |
| <p>Direct the stub to erase <var>length</var> bytes of flash starting at |
| <var>addr</var>. The region may enclose any number of flash blocks, but |
| its start and end must fall on block boundaries, as indicated by the |
| flash block size appearing in the memory map (see <a href="Memory-Map-Format.html#Memory-Map-Format">Memory Map Format</a>). <small>GDB</small> groups flash memory programming operations |
| together, and sends a ‘<samp>vFlashDone</samp>’ request after each group; the |
| stub is allowed to delay erase operation until the ‘<samp>vFlashDone</samp>’ |
| packet is received. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>vFlashWrite:<var>addr</var>:<var>XX…</var></samp>’</dt> |
| <dd><a name="index-vFlashWrite-packet"></a> |
| <p>Direct the stub to write data to flash address <var>addr</var>. The data |
| is passed in binary form using the same encoding as for the ‘<samp>X</samp>’ |
| packet (see <a href="Overview.html#Binary-Data">Binary Data</a>). The memory ranges specified by |
| ‘<samp>vFlashWrite</samp>’ packets preceding a ‘<samp>vFlashDone</samp>’ packet must |
| not overlap, and must appear in order of increasing addresses |
| (although ‘<samp>vFlashErase</samp>’ packets for higher addresses may already |
| have been received; the ordering is guaranteed only between |
| ‘<samp>vFlashWrite</samp>’ packets). If a packet writes to an address that was |
| neither erased by a preceding ‘<samp>vFlashErase</samp>’ packet nor by some other |
| target-specific method, the results are unpredictable. |
| </p> |
| |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E.memtype</samp>’</dt> |
| <dd><p>for vFlashWrite addressing non-flash memory |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>vFlashDone</samp>’</dt> |
| <dd><a name="index-vFlashDone-packet"></a> |
| <p>Indicate to the stub that flash programming operation is finished. |
| The stub is permitted to delay or batch the effects of a group of |
| ‘<samp>vFlashErase</samp>’ and ‘<samp>vFlashWrite</samp>’ packets until a |
| ‘<samp>vFlashDone</samp>’ packet is received. The contents of the affected |
| regions of flash memory are unpredictable until the ‘<samp>vFlashDone</samp>’ |
| request is completed. |
| </p> |
| </dd> |
| <dt>‘<samp>vKill;<var>pid</var></samp>’</dt> |
| <dd><a name="index-vKill-packet"></a> |
| <a name="vKill-packet"></a><p>Kill the process with the specified process ID <var>pid</var>, which is a |
| hexadecimal integer identifying the process. This packet is used in |
| preference to ‘<samp>k</samp>’ when multiprocess protocol extensions are |
| supported; see <a href="General-Query-Packets.html#multiprocess-extensions">multiprocess extensions</a>. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>E <var>nn</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>vRun;<var>filename</var><span class="roman">[</span>;<var>argument</var><span class="roman">]</span>…</samp>’</dt> |
| <dd><a name="index-vRun-packet"></a> |
| <p>Run the program <var>filename</var>, passing it each <var>argument</var> on its |
| command line. The file and arguments are hex-encoded strings. If |
| <var>filename</var> is an empty string, the stub may use a default program |
| (e.g. the last program run). The program is created in the stopped |
| state. |
| </p> |
| |
| <p>This packet is only available in extended mode (see <a href="#extended-mode">extended mode</a>). |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>E <var>nn</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| <dt>‘<samp><span class="roman">Any stop packet</span></samp>’</dt> |
| <dd><p>for success (see <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>) |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>vStopped</samp>’</dt> |
| <dd><a name="index-vStopped-packet"></a> |
| <p>See <a href="Notification-Packets.html#Notification-Packets">Notification Packets</a>. |
| </p> |
| </dd> |
| <dt>‘<samp>X <var>addr</var>,<var>length</var>:<var>XX…</var></samp>’</dt> |
| <dd><a name="X-packet"></a><a name="index-X-packet"></a> |
| <p>Write data to memory, where the data is transmitted in binary. |
| Memory is specified by its address <var>addr</var> and number of addressable memory |
| units <var>length</var> (see <a href="Memory.html#addressable-memory-unit">addressable memory unit</a>); |
| ‘<samp><var>XX</var>…</samp>’ is binary data (see <a href="Overview.html#Binary-Data">Binary Data</a>). |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>for success |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>z <var>type</var>,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dt>‘<samp>Z <var>type</var>,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dd><a name="insert-breakpoint-or-watchpoint-packet"></a><a name="index-z-packet"></a> |
| <a name="index-Z-packets"></a> |
| <p>Insert (‘<samp>Z</samp>’) or remove (‘<samp>z</samp>’) a <var>type</var> breakpoint or |
| watchpoint starting at address <var>address</var> of kind <var>kind</var>. |
| </p> |
| <p>Each breakpoint and watchpoint packet <var>type</var> is documented |
| separately. |
| </p> |
| <p><em>Implementation notes: A remote target shall return an empty string |
| for an unrecognized breakpoint or watchpoint packet <var>type</var>. A |
| remote target shall support either both or neither of a given |
| ‘<samp>Z<var>type</var>…</samp>’ and ‘<samp>z<var>type</var>…</samp>’ packet pair. To |
| avoid potential problems with duplicate packets, the operations should |
| be implemented in an idempotent way.</em> |
| </p> |
| </dd> |
| <dt>‘<samp>z0,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dt>‘<samp>Z0,<var>addr</var>,<var>kind</var><span class="roman">[</span>;<var>cond_list</var>…<span class="roman">]</span><span class="roman">[</span>;cmds:<var>persist</var>,<var>cmd_list</var>…<span class="roman">]</span></samp>’</dt> |
| <dd><a name="index-z0-packet"></a> |
| <a name="index-Z0-packet"></a> |
| <p>Insert (‘<samp>Z0</samp>’) or remove (‘<samp>z0</samp>’) a memory breakpoint at address |
| <var>addr</var> of type <var>kind</var>. |
| </p> |
| <p>A memory breakpoint is implemented by replacing the instruction at |
| <var>addr</var> with a software breakpoint or trap instruction. The |
| <var>kind</var> is target-specific and typically indicates the size of |
| the breakpoint in bytes that should be inserted. E.g., the <small>ARM</small> |
| and <small>MIPS</small> can insert either a 2 or 4 byte breakpoint. Some |
| architectures have additional meanings for <var>kind</var>; |
| <var>cond_list</var> is an optional list of conditional expressions in bytecode |
| form that should be evaluated on the target’s side. These are the |
| conditions that should be taken into consideration when deciding if |
| the breakpoint trigger should be reported back to <var>GDBN</var>. |
| </p> |
| <p>See also the ‘<samp>swbreak</samp>’ stop reason (see <a href="Stop-Reply-Packets.html#swbreak-stop-reason">swbreak stop reason</a>) |
| for how to best report a memory breakpoint event to <small>GDB</small>. |
| </p> |
| <p>The <var>cond_list</var> parameter is comprised of a series of expressions, |
| concatenated without separators. Each expression has the following form: |
| </p> |
| <dl compact="compact"> |
| <dt>‘<samp>X <var>len</var>,<var>expr</var></samp>’</dt> |
| <dd><p><var>len</var> is the length of the bytecode expression and <var>expr</var> is the |
| actual conditional expression in bytecode form. |
| </p> |
| </dd> |
| </dl> |
| |
| <p>The optional <var>cmd_list</var> parameter introduces commands that may be |
| run on the target, rather than being reported back to <small>GDB</small>. |
| The parameter starts with a numeric flag <var>persist</var>; if the flag is |
| nonzero, then the breakpoint may remain active and the commands |
| continue to be run even when <small>GDB</small> disconnects from the target. |
| Following this flag is a series of expressions concatenated with no |
| separators. Each expression has the following form: |
| </p> |
| <dl compact="compact"> |
| <dt>‘<samp>X <var>len</var>,<var>expr</var></samp>’</dt> |
| <dd><p><var>len</var> is the length of the bytecode expression and <var>expr</var> is the |
| actual conditional expression in bytecode form. |
| </p> |
| </dd> |
| </dl> |
| |
| <p>see <a href="Architecture_002dSpecific-Protocol-Details.html#Architecture_002dSpecific-Protocol-Details">Architecture-Specific Protocol Details</a>. |
| </p> |
| <p><em>Implementation note: It is possible for a target to copy or move |
| code that contains memory breakpoints (e.g., when implementing |
| overlays). The behavior of this packet, in the presence of such a |
| target, is not defined.</em> |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>success |
| </p></dd> |
| <dt>‘<samp><!-- /@w --></samp>’</dt> |
| <dd><p>not supported |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>z1,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dt>‘<samp>Z1,<var>addr</var>,<var>kind</var><span class="roman">[</span>;<var>cond_list</var>…<span class="roman">]</span></samp>’</dt> |
| <dd><a name="index-z1-packet"></a> |
| <a name="index-Z1-packet"></a> |
| <p>Insert (‘<samp>Z1</samp>’) or remove (‘<samp>z1</samp>’) a hardware breakpoint at |
| address <var>addr</var>. |
| </p> |
| <p>A hardware breakpoint is implemented using a mechanism that is not |
| dependant on being able to modify the target’s memory. The <var>kind</var> |
| and <var>cond_list</var> have the same meaning as in ‘<samp>Z0</samp>’ packets. |
| </p> |
| <p><em>Implementation note: A hardware breakpoint is not affected by code |
| movement.</em> |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>success |
| </p></dd> |
| <dt>‘<samp><!-- /@w --></samp>’</dt> |
| <dd><p>not supported |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>z2,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dt>‘<samp>Z2,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dd><a name="index-z2-packet"></a> |
| <a name="index-Z2-packet"></a> |
| <p>Insert (‘<samp>Z2</samp>’) or remove (‘<samp>z2</samp>’) a write watchpoint at <var>addr</var>. |
| The number of bytes to watch is specified by <var>kind</var>. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>success |
| </p></dd> |
| <dt>‘<samp><!-- /@w --></samp>’</dt> |
| <dd><p>not supported |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>z3,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dt>‘<samp>Z3,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dd><a name="index-z3-packet"></a> |
| <a name="index-Z3-packet"></a> |
| <p>Insert (‘<samp>Z3</samp>’) or remove (‘<samp>z3</samp>’) a read watchpoint at <var>addr</var>. |
| The number of bytes to watch is specified by <var>kind</var>. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>success |
| </p></dd> |
| <dt>‘<samp><!-- /@w --></samp>’</dt> |
| <dd><p>not supported |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| <dt>‘<samp>z4,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dt>‘<samp>Z4,<var>addr</var>,<var>kind</var></samp>’</dt> |
| <dd><a name="index-z4-packet"></a> |
| <a name="index-Z4-packet"></a> |
| <p>Insert (‘<samp>Z4</samp>’) or remove (‘<samp>z4</samp>’) an access watchpoint at <var>addr</var>. |
| The number of bytes to watch is specified by <var>kind</var>. |
| </p> |
| <p>Reply: |
| </p><dl compact="compact"> |
| <dt>‘<samp>OK</samp>’</dt> |
| <dd><p>success |
| </p></dd> |
| <dt>‘<samp><!-- /@w --></samp>’</dt> |
| <dd><p>not supported |
| </p></dd> |
| <dt>‘<samp>E <var>NN</var></samp>’</dt> |
| <dd><p>for an error |
| </p></dd> |
| </dl> |
| |
| </dd> |
| </dl> |
| |
| <hr> |
| <div class="header"> |
| <p> |
| Next: <a href="Stop-Reply-Packets.html#Stop-Reply-Packets" accesskey="n" rel="next">Stop Reply Packets</a>, Previous: <a href="Overview.html#Overview" accesskey="p" rel="prev">Overview</a>, Up: <a href="Remote-Protocol.html#Remote-Protocol" accesskey="u" rel="up">Remote Protocol</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p> |
| </div> |
| |
| |
| |
| </body> |
| </html> |
