| <html lang="en"> |
| <head> |
| <title>Packets - 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="Overview.html#Overview" title="Overview"> |
| <link rel="next" href="Stop-Reply-Packets.html#Stop-Reply-Packets" title="Stop Reply Packets"> |
| <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="Packets"></a> |
| <p> |
| Next: <a rel="next" accesskey="n" href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, |
| Previous: <a rel="previous" accesskey="p" href="Overview.html#Overview">Overview</a>, |
| Up: <a rel="up" accesskey="u" href="Remote-Protocol.html#Remote-Protocol">Remote Protocol</a> |
| <hr> |
| </div> |
| |
| <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>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 <span class="sc">gdb</span> packet uses spaces to |
| separate its components. For example, a template like ‘<samp><span class="samp">foo |
| </span><var>bar</var> <var>baz</var></samp>’ describes a packet beginning with the three ASCII |
| bytes ‘<samp><span class="samp">foo</span></samp>’, followed by a <var>bar</var>, followed directly by a |
| <var>baz</var>. <span class="sc">gdb</span> does not transmit a space character between the |
| ‘<samp><span class="samp">foo</span></samp>’ and the <var>bar</var>, or between the <var>bar</var> and the |
| <var>baz</var>. |
| |
| <p><a name="index-g_t_0040var_007bthread_002did_007d_002c-in-remote-protocol-3422"></a><a name="thread_002did-syntax"></a>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><span class="samp">-1</span></samp>’ to indicate all threads, or ‘<samp><span class="samp">0</span></samp>’ to |
| pick any thread. |
| |
| <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><span class="samp">p</span><var>pid</var><span class="samp">.</span><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><span class="samp">-1</span></samp>’ |
| to indicate all processes or threads (respectively), or ‘<samp><span class="samp">0</span></samp>’ to |
| indicate an arbitrary process or thread. Specifying just a process, as |
| ‘<samp><span class="samp">p</span><var>pid</var></samp>’, is equivalent to ‘<samp><span class="samp">p</span><var>pid</var><span class="samp">.-1</span></samp>’. It is an |
| error to specify all processes but a specific thread, such as |
| ‘<samp><span class="samp">p-1.</span><var>tid</var></samp>’. Note that the ‘<samp><span class="samp">p</span></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>The multiprocess <var>thread-id</var> syntax extensions are only used if both |
| <span class="sc">gdb</span> and the stub report support for the ‘<samp><span class="samp">multiprocess</span></samp>’ |
| feature using ‘<samp><span class="samp">qSupported</span></samp>’. See <a href="multiprocess-extensions.html#multiprocess-extensions">multiprocess extensions</a>, for |
| more information. |
| |
| <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>Here are the packet descriptions. |
| |
| <dl> |
| <dt>‘<samp><span class="samp">!</span></samp>’<dd><a name="index-g_t_0040samp_007b_0021_007d-packet-3423"></a><a name="extended-mode"></a>Enable extended mode. In extended mode, the remote server is made |
| persistent. The ‘<samp><span class="samp">R</span></samp>’ packet is used to restart the program being |
| debugged. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>The remote target both supports and has enabled extended mode. |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">?</span></samp>’<dd><a name="index-g_t_0040samp_007b_003f_007d-packet-3424"></a><a name="g_t_003f-packet"></a>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>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <br><dt>‘<samp><span class="samp">A </span><var>arglen</var><span class="samp">,</span><var>argnum</var><span class="samp">,</span><var>arg</var><span class="samp">,...</span></samp>’<dd><a name="index-g_t_0040samp_007bA_007d-packet-3425"></a>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>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>The arguments were set. |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>An error occurred. |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">b </span><var>baud</var></samp>’<dd><a name="index-g_t_0040samp_007bb_007d-packet-3426"></a>(Don't use this packet; its behavior is not well-defined.) |
| Change the serial line speed to <var>baud</var>. |
| |
| <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>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> |
| |
| <br><dt>‘<samp><span class="samp">B </span><var>addr</var><span class="samp">,</span><var>mode</var></samp>’<dd><a name="index-g_t_0040samp_007bB_007d-packet-3427"></a>Set (<var>mode</var> is ‘<samp><span class="samp">S</span></samp>’) or clear (<var>mode</var> is ‘<samp><span class="samp">C</span></samp>’) a |
| breakpoint at <var>addr</var>. |
| |
| <p>Don't use this packet. Use the ‘<samp><span class="samp">Z</span></samp>’ and ‘<samp><span class="samp">z</span></samp>’ packets instead |
| (see <a href="insert-breakpoint-or-watchpoint-packet.html#insert-breakpoint-or-watchpoint-packet">insert breakpoint or watchpoint packet</a>). |
| |
| <p><a name="index-g_t_0040samp_007bbc_007d-packet-3428"></a><a name="bc"></a><br><dt>‘<samp><span class="samp">bc</span></samp>’<dd>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>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <p><a name="index-g_t_0040samp_007bbs_007d-packet-3429"></a><a name="bs"></a><br><dt>‘<samp><span class="samp">bs</span></samp>’<dd>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>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <br><dt>‘<samp><span class="samp">c [</span><var>addr</var><span class="samp">]</span></samp>’<dd><a name="index-g_t_0040samp_007bc_007d-packet-3430"></a>Continue at <var>addr</var>, which is the address to resume. If <var>addr</var> |
| is omitted, resume at current address. |
| |
| <p>This packet is deprecated for multi-threading support. See <a href="vCont-packet.html#vCont-packet">vCont packet</a>. |
| |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <br><dt>‘<samp><span class="samp">C </span><var>sig</var><span class="samp">[;</span><var>addr</var><span class="samp">]</span></samp>’<dd><a name="index-g_t_0040samp_007bC_007d-packet-3431"></a>Continue with signal <var>sig</var> (hex signal number). If |
| ‘<samp><span class="samp">;</span><var>addr</var></samp>’ is omitted, resume at same address. |
| |
| <p>This packet is deprecated for multi-threading support. See <a href="vCont-packet.html#vCont-packet">vCont packet</a>. |
| |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <br><dt>‘<samp><span class="samp">d</span></samp>’<dd><a name="index-g_t_0040samp_007bd_007d-packet-3432"></a>Toggle debug flag. |
| |
| <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>). |
| |
| <br><dt>‘<samp><span class="samp">D</span></samp>’<dt>‘<samp><span class="samp">D;</span><var>pid</var></samp>’<dd><a name="index-g_t_0040samp_007bD_007d-packet-3433"></a>The first form of the packet is used to detach <span class="sc">gdb</span> from the |
| remote system. It is sent to the remote target |
| before <span class="sc">gdb</span> disconnects via the <code>detach</code> command. |
| |
| <p>The second form, including a process ID, is used when multiprocess |
| protocol extensions are enabled (see <a href="multiprocess-extensions.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>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">F </span><var>RC</var><span class="samp">,</span><var>EE</var><span class="samp">,</span><var>CF</var><span class="samp">;</span><var>XX</var></samp>’<dd><a name="index-g_t_0040samp_007bF_007d-packet-3434"></a>A reply from <span class="sc">gdb</span> to an ‘<samp><span class="samp">F</span></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. |
| |
| <br><dt>‘<samp><span class="samp">g</span></samp>’<dd><a name="read-registers-packet"></a><a name="index-g_t_0040samp_007bg_007d-packet-3435"></a>Read general registers. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><var>XX<small class="dots">...</small></var></samp>’<dd>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><span class="samp">g</span></samp>’ packet are |
| determined by the <span class="sc">gdb</span> internal gdbarch functions |
| <code>DEPRECATED_REGISTER_RAW_SIZE</code> and <code>gdbarch_register_name</code>. |
| |
| <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><span class="samp">x</span></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 <span class="sc">gdb</span> that |
| registers 0 and 2 have not been collected, while registers 1 and 3 |
| have been collected, and both have zero value: |
| |
| <pre class="smallexample"> -> <code>g</code> |
| <- <code>xxxxxxxx00000000xxxxxxxx00000000</code> |
| </pre> |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error. |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">G </span><var>XX<small class="dots">...</small></var></samp>’<dd><a name="index-g_t_0040samp_007bG_007d-packet-3436"></a>Write general registers. See <a href="read-registers-packet.html#read-registers-packet">read registers packet</a>, for a |
| description of the <var>XX<small class="dots">...</small></var> data. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">H </span><var>op</var> <var>thread-id</var></samp>’<dd><a name="index-g_t_0040samp_007bH_007d-packet-3437"></a>Set thread for subsequent operations (‘<samp><span class="samp">m</span></samp>’, ‘<samp><span class="samp">M</span></samp>’, ‘<samp><span class="samp">g</span></samp>’, |
| ‘<samp><span class="samp">G</span></samp>’, et.al.). Depending on the operation to be performed, <var>op</var> |
| should be ‘<samp><span class="samp">c</span></samp>’ for step and continue operations (note that this |
| is deprecated, supporting the ‘<samp><span class="samp">vCont</span></samp>’ command is a better |
| option), and ‘<samp><span class="samp">g</span></samp>’ for other operations. The thread designator |
| <var>thread-id</var> has the format and interpretation described in |
| <a href="thread_002did-syntax.html#thread_002did-syntax">thread-id syntax</a>. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <!-- FIXME: JTC: --> |
| <!-- 'H': How restrictive (or permissive) is the thread model. If a --> |
| <!-- thread is selected and stopped, are other threads allowed --> |
| <!-- to continue to execute? As I mentioned above, I think the --> |
| <!-- semantics of each command when a thread is selected must be --> |
| <!-- described. For example: --> |
| <!-- 'g': If the stub supports threads and a specific thread is --> |
| <!-- selected, returns the register block from that thread; --> |
| <!-- otherwise returns current registers. --> |
| <!-- 'G' If the stub supports threads and a specific thread is --> |
| <!-- selected, sets the registers of the register block of --> |
| <!-- that thread; otherwise sets current registers. --> |
| <br><dt>‘<samp><span class="samp">i [</span><var>addr</var><span class="samp">[,</span><var>nnn</var><span class="samp">]]</span></samp>’<dd><a name="cycle-step-packet"></a><a name="index-g_t_0040samp_007bi_007d-packet-3438"></a>Step the remote target by a single clock cycle. If ‘<samp><span class="samp">,</span><var>nnn</var></samp>’ is |
| present, cycle step <var>nnn</var> cycles. If <var>addr</var> is present, cycle |
| step starting at that address. |
| |
| <br><dt>‘<samp><span class="samp">I</span></samp>’<dd><a name="index-g_t_0040samp_007bI_007d-packet-3439"></a>Signal, then cycle step. See <a href="step-with-signal-packet.html#step-with-signal-packet">step with signal packet</a>. See <a href="cycle-step-packet.html#cycle-step-packet">cycle step packet</a>. |
| |
| <br><dt>‘<samp><span class="samp">k</span></samp>’<dd><a name="index-g_t_0040samp_007bk_007d-packet-3440"></a>Kill request. |
| |
| <p>The exact effect of this packet is not specified. |
| |
| <p>For a bare-metal target, it may power cycle or reset the target |
| system. For that reason, the ‘<samp><span class="samp">k</span></samp>’ packet has no reply. |
| |
| <p>For a single-process target, it may kill that process if possible. |
| |
| <p>A multiple-process target may choose to kill just one process, or all |
| that are under <span class="sc">gdb</span>'s control. For more precise control, use |
| the vKill packet (see <a href="vKill-packet.html#vKill-packet">vKill packet</a>). |
| |
| <p>If the target system immediately closes the connection in response to |
| ‘<samp><span class="samp">k</span></samp>’, <span class="sc">gdb</span> does not consider the lack of packet |
| acknowledgment to be an error, and assumes the kill was successful. |
| |
| <p>If connected using <kbd>target extended-remote</kbd>, and the target does |
| not close the connection in response to a kill request, <span class="sc">gdb</span> |
| probes the target state as if a new connection was opened |
| (see <a href="_003f-packet.html#g_t_003f-packet">? packet</a>). |
| |
| <br><dt>‘<samp><span class="samp">m </span><var>addr</var><span class="samp">,</span><var>length</var></samp>’<dd><a name="index-g_t_0040samp_007bm_007d-packet-3441"></a>Read <var>length</var> addressable memory units starting at address <var>addr</var> |
| (see <a href="addressable-memory-unit.html#addressable-memory-unit">addressable memory unit</a>). Note that <var>addr</var> may not be aligned to |
| any particular boundary. |
| |
| <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-3442"></a><a name="index-size-of-remote-memory-accesses-3443"></a><a name="index-memory_002c-alignment-and-size-of-remote-accesses-3444"></a> |
| Reply: |
| <dl> |
| <dt>‘<samp><var>XX<small class="dots">...</small></var></samp>’<dd>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. |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd><var>NN</var> is errno |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">M </span><var>addr</var><span class="samp">,</span><var>length</var><span class="samp">:</span><var>XX<small class="dots">...</small></var></samp>’<dd><a name="index-g_t_0040samp_007bM_007d-packet-3445"></a>Write <var>length</var> addressable memory units starting at address <var>addr</var> |
| (see <a href="addressable-memory-unit.html#addressable-memory-unit">addressable memory unit</a>). The data is given by <var>XX<small class="dots">...</small></var>; each |
| byte is transmitted as a two-digit hexadecimal number. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error (this includes the case where only part of the data was |
| written). |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">p </span><var>n</var></samp>’<dd><a name="index-g_t_0040samp_007bp_007d-packet-3446"></a>Read the value of register <var>n</var>; <var>n</var> is in hex. |
| See <a href="read-registers-packet.html#read-registers-packet">read registers packet</a>, for a description of how the returned |
| register value is encoded. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><var>XX<small class="dots">...</small></var></samp>’<dd>the register's value |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| <br><dt>‘<samp><span class="samp"><!-- /@w --></span></samp>’<dd>Indicating an unrecognized <var>query</var>. |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">P </span><var>n<small class="dots">...</small></var><span class="samp">=</span><var>r<small class="dots">...</small></var></samp>’<dd><a name="write-register-packet"></a><a name="index-g_t_0040samp_007bP_007d-packet-3447"></a>Write register <var>n<small class="dots">...</small></var> with value <var>r<small class="dots">...</small></var>. The register |
| number <var>n</var> is in hexadecimal, and <var>r<small class="dots">...</small></var> contains two hex |
| digits for each byte in the register (target byte order). |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">q </span><var>name</var> <var>params</var><span class="samp">...</span></samp>’<dt>‘<samp><span class="samp">Q </span><var>name</var> <var>params</var><span class="samp">...</span></samp>’<dd><a name="index-g_t_0040samp_007bq_007d-packet-3448"></a><a name="index-g_t_0040samp_007bQ_007d-packet-3449"></a>General query (‘<samp><span class="samp">q</span></samp>’) and set (‘<samp><span class="samp">Q</span></samp>’). These packets are |
| described fully in <a href="General-Query-Packets.html#General-Query-Packets">General Query Packets</a>. |
| |
| <br><dt>‘<samp><span class="samp">r</span></samp>’<dd><a name="index-g_t_0040samp_007br_007d-packet-3450"></a>Reset the entire system. |
| |
| <p>Don't use this packet; use the ‘<samp><span class="samp">R</span></samp>’ packet instead. |
| |
| <br><dt>‘<samp><span class="samp">R </span><var>XX</var></samp>’<dd><a name="index-g_t_0040samp_007bR_007d-packet-3451"></a>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.html#extended-mode">extended mode</a>). |
| |
| <p>The ‘<samp><span class="samp">R</span></samp>’ packet has no reply. |
| |
| <br><dt>‘<samp><span class="samp">s [</span><var>addr</var><span class="samp">]</span></samp>’<dd><a name="index-g_t_0040samp_007bs_007d-packet-3452"></a>Single step, resuming at <var>addr</var>. If |
| <var>addr</var> is omitted, resume at same address. |
| |
| <p>This packet is deprecated for multi-threading support. See <a href="vCont-packet.html#vCont-packet">vCont packet</a>. |
| |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <br><dt>‘<samp><span class="samp">S </span><var>sig</var><span class="samp">[;</span><var>addr</var><span class="samp">]</span></samp>’<dd><a name="step-with-signal-packet"></a><a name="index-g_t_0040samp_007bS_007d-packet-3453"></a>Step with signal. This is analogous to the ‘<samp><span class="samp">C</span></samp>’ packet, but |
| requests a single-step, rather than a normal resumption of execution. |
| |
| <p>This packet is deprecated for multi-threading support. See <a href="vCont-packet.html#vCont-packet">vCont packet</a>. |
| |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <br><dt>‘<samp><span class="samp">t </span><var>addr</var><span class="samp">:</span><var>PP</var><span class="samp">,</span><var>MM</var></samp>’<dd><a name="index-g_t_0040samp_007bt_007d-packet-3454"></a>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>. |
| |
| <br><dt>‘<samp><span class="samp">T </span><var>thread-id</var></samp>’<dd><a name="index-g_t_0040samp_007bT_007d-packet-3455"></a>Find out if the thread <var>thread-id</var> is alive. See <a href="thread_002did-syntax.html#thread_002did-syntax">thread-id syntax</a>. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>thread is still alive |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>thread is dead |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">v</span></samp>’<dd>Packets starting with ‘<samp><span class="samp">v</span></samp>’ are identified by a multi-letter name, |
| up to the first ‘<samp><span class="samp">;</span></samp>’ or ‘<samp><span class="samp">?</span></samp>’ (or the end of the packet). |
| |
| <br><dt>‘<samp><span class="samp">vAttach;</span><var>pid</var></samp>’<dd><a name="index-g_t_0040samp_007bvAttach_007d-packet-3456"></a>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. |
| |
| <!-- In non-stop mode, on a successful vAttach, the stub should set the --> |
| <!-- current thread to a thread of the newly-attached process. After --> |
| <!-- attaching, GDB queries for the attached process's thread ID with qC. --> |
| <!-- Also note that, from a user perspective, whether or not the --> |
| <!-- target is stopped on attach in non-stop mode depends on whether you --> |
| <!-- use the foreground or background version of the attach command, not --> |
| <!-- on what vAttach does; GDB does the right thing with respect to either --> |
| <!-- stopping or restarting threads. --> |
| <p>This packet is only available in extended mode (see <a href="extended-mode.html#extended-mode">extended mode</a>). |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">E </span><var>nn</var></samp>’<dd>for an error |
| <br><dt>‘<samp><span class="samp">Any stop packet</span></samp>’<dd>for success in all-stop mode (see <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>) |
| <br><dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success in non-stop mode (see <a href="Remote-Non_002dStop.html#Remote-Non_002dStop">Remote Non-Stop</a>) |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">vCont[;</span><var>action</var><span class="samp">[:</span><var>thread-id</var><span class="samp">]]...</span></samp>’<dd><a name="index-g_t_0040samp_007bvCont_007d-packet-3457"></a><a name="vCont-packet"></a>Resume the inferior, specifying different actions for each thread. |
| |
| <p>For each inferior thread, the leftmost action with a matching |
| <var>thread-id</var> is applied. Threads that don't match any action |
| remain in their current state. Thread IDs are specified using the |
| syntax described in <a href="thread_002did-syntax.html#thread_002did-syntax">thread-id syntax</a>. If multiprocess |
| extensions (see <a href="multiprocess-extensions.html#multiprocess-extensions">multiprocess extensions</a>) are supported, actions |
| can be specified to match all threads in a process by using the |
| ‘<samp><span class="samp">p</span><var>pid</var><span class="samp">.-1</span></samp>’ form of the <var>thread-id</var>. An action with no |
| <var>thread-id</var> matches all threads. Specifying no actions is an |
| error. |
| |
| <p>Currently supported actions are: |
| |
| <dl> |
| <dt>‘<samp><span class="samp">c</span></samp>’<dd>Continue. |
| <br><dt>‘<samp><span class="samp">C </span><var>sig</var></samp>’<dd>Continue with signal <var>sig</var>. The signal <var>sig</var> should be two hex digits. |
| <br><dt>‘<samp><span class="samp">s</span></samp>’<dd>Step. |
| <br><dt>‘<samp><span class="samp">S </span><var>sig</var></samp>’<dd>Step with signal <var>sig</var>. The signal <var>sig</var> should be two hex digits. |
| <br><dt>‘<samp><span class="samp">t</span></samp>’<dd>Stop. |
| <br><dt>‘<samp><span class="samp">r </span><var>start</var><span class="samp">,</span><var>end</var></samp>’<dd>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="range-stepping.html#range-stepping">range stepping</a>. |
| |
| <p>If the range is empty (<var>start</var> == <var>end</var>), then the action |
| becomes equivalent to the ‘<samp><span class="samp">s</span></samp>’ action. In other words, |
| single-step once, and report the stop (even if the stepped instruction |
| jumps to <var>start</var>). |
| |
| <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.) |
| |
| </dl> |
| |
| <p>The optional argument <var>addr</var> normally associated with the |
| ‘<samp><span class="samp">c</span></samp>’, ‘<samp><span class="samp">C</span></samp>’, ‘<samp><span class="samp">s</span></samp>’, and ‘<samp><span class="samp">S</span></samp>’ packets is |
| not supported in ‘<samp><span class="samp">vCont</span></samp>’. |
| |
| <p>The ‘<samp><span class="samp">t</span></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><span class="samp">t</span></samp>’ action, |
| the corresponding stop reply should indicate that the thread has stopped with |
| signal ‘<samp><span class="samp">0</span></samp>’, regardless of whether the target uses some other signal |
| as an implementation detail. |
| |
| <p>The server must ignore ‘<samp><span class="samp">c</span></samp>’, ‘<samp><span class="samp">C</span></samp>’, ‘<samp><span class="samp">s</span></samp>’, ‘<samp><span class="samp">S</span></samp>’, and |
| ‘<samp><span class="samp">r</span></samp>’ actions for threads that are already running. Conversely, |
| the server must ignore ‘<samp><span class="samp">t</span></samp>’ actions for threads that are already |
| stopped. |
| |
| <p><em>Note:</em> In non-stop mode, a thread is considered running until |
| <span class="sc">gdb</span> acknowleges an asynchronous stop notification for it with |
| the ‘<samp><span class="samp">vStopped</span></samp>’ packet (see <a href="Remote-Non_002dStop.html#Remote-Non_002dStop">Remote Non-Stop</a>). |
| |
| <p>The stub must support ‘<samp><span class="samp">vCont</span></samp>’ if it reports support for |
| multiprocess extensions (see <a href="multiprocess-extensions.html#multiprocess-extensions">multiprocess extensions</a>). |
| |
| <p>Reply: |
| See <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>, for the reply specifications. |
| |
| <br><dt>‘<samp><span class="samp">vCont?</span></samp>’<dd><a name="index-g_t_0040samp_007bvCont_003f_007d-packet-3458"></a>Request a list of actions supported by the ‘<samp><span class="samp">vCont</span></samp>’ packet. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">vCont[;</span><var>action</var><span class="samp">...]</span></samp>’<dd>The ‘<samp><span class="samp">vCont</span></samp>’ packet is supported. Each <var>action</var> is a supported |
| command in the ‘<samp><span class="samp">vCont</span></samp>’ packet. |
| <br><dt>‘<samp><span class="samp"><!-- /@w --></span></samp>’<dd>The ‘<samp><span class="samp">vCont</span></samp>’ packet is not supported. |
| </dl> |
| |
| <p><a name="vCtrlC-packet"></a><br><dt>‘<samp><span class="samp">vCtrlC</span></samp>’<dd><a name="index-g_t_0040samp_007bvCtrlC_007d-packet-3459"></a>Interrupt remote target as if a control-C was pressed on the remote |
| terminal. This is the equivalent to reacting to the <code>^C</code> |
| (‘<samp><span class="samp">\003</span></samp>’, the control-C character) character in all-stop mode |
| while the target is running, except this works in non-stop mode. |
| See <a href="interrupting-remote-targets.html#interrupting-remote-targets">interrupting remote targets</a>, for more info on the all-stop |
| variant. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">E </span><var>nn</var></samp>’<dd>for an error |
| <br><dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">vFile:</span><var>operation</var><span class="samp">:</span><var>parameter</var><span class="samp">...</span></samp>’<dd><a name="index-g_t_0040samp_007bvFile_007d-packet-3460"></a>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>. |
| |
| <br><dt>‘<samp><span class="samp">vFlashErase:</span><var>addr</var><span class="samp">,</span><var>length</var></samp>’<dd><a name="index-g_t_0040samp_007bvFlashErase_007d-packet-3461"></a>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>). <span class="sc">gdb</span> groups flash memory programming operations |
| together, and sends a ‘<samp><span class="samp">vFlashDone</span></samp>’ request after each group; the |
| stub is allowed to delay erase operation until the ‘<samp><span class="samp">vFlashDone</span></samp>’ |
| packet is received. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">vFlashWrite:</span><var>addr</var><span class="samp">:</span><var>XX<small class="dots">...</small></var></samp>’<dd><a name="index-g_t_0040samp_007bvFlashWrite_007d-packet-3462"></a>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><span class="samp">X</span></samp>’ |
| packet (see <a href="Binary-Data.html#Binary-Data">Binary Data</a>). The memory ranges specified by |
| ‘<samp><span class="samp">vFlashWrite</span></samp>’ packets preceding a ‘<samp><span class="samp">vFlashDone</span></samp>’ packet must |
| not overlap, and must appear in order of increasing addresses |
| (although ‘<samp><span class="samp">vFlashErase</span></samp>’ packets for higher addresses may already |
| have been received; the ordering is guaranteed only between |
| ‘<samp><span class="samp">vFlashWrite</span></samp>’ packets). If a packet writes to an address that was |
| neither erased by a preceding ‘<samp><span class="samp">vFlashErase</span></samp>’ packet nor by some other |
| target-specific method, the results are unpredictable. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E.memtype</span></samp>’<dd>for vFlashWrite addressing non-flash memory |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">vFlashDone</span></samp>’<dd><a name="index-g_t_0040samp_007bvFlashDone_007d-packet-3463"></a>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><span class="samp">vFlashErase</span></samp>’ and ‘<samp><span class="samp">vFlashWrite</span></samp>’ packets until a |
| ‘<samp><span class="samp">vFlashDone</span></samp>’ packet is received. The contents of the affected |
| regions of flash memory are unpredictable until the ‘<samp><span class="samp">vFlashDone</span></samp>’ |
| request is completed. |
| |
| <br><dt>‘<samp><span class="samp">vKill;</span><var>pid</var></samp>’<dd><a name="index-g_t_0040samp_007bvKill_007d-packet-3464"></a><a name="vKill-packet"></a>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><span class="samp">k</span></samp>’ when multiprocess protocol extensions are |
| supported; see <a href="multiprocess-extensions.html#multiprocess-extensions">multiprocess extensions</a>. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">E </span><var>nn</var></samp>’<dd>for an error |
| <br><dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">vMustReplyEmpty</span></samp>’<dd><a name="index-g_t_0040samp_007bvMustReplyEmpty_007d-packet-3465"></a>The correct reply to an unknown ‘<samp><span class="samp">v</span></samp>’ packet is to return the empty |
| string, however, some older versions of <samp><span class="command">gdbserver</span></samp> would |
| incorrectly return ‘<samp><span class="samp">OK</span></samp>’ for unknown ‘<samp><span class="samp">v</span></samp>’ packets. |
| |
| <p>The ‘<samp><span class="samp">vMustReplyEmpty</span></samp>’ is used as a feature test to check how |
| <samp><span class="command">gdbserver</span></samp> handles unknown packets, it is important that this |
| packet be handled in the same way as other unknown ‘<samp><span class="samp">v</span></samp>’ packets. |
| If this packet is handled differently to other unknown ‘<samp><span class="samp">v</span></samp>’ |
| packets then it is possile that <span class="sc">gdb</span> may run into problems in |
| other areas, specifically around use of ‘<samp><span class="samp">vFile:setfs:</span></samp>’. |
| |
| <br><dt>‘<samp><span class="samp">vRun;</span><var>filename</var><span class="samp">[;</span><var>argument</var><span class="samp">]...</span></samp>’<dd><a name="index-g_t_0040samp_007bvRun_007d-packet-3466"></a>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. |
| |
| <!-- FIXME: What about non-stop mode? --> |
| <p>This packet is only available in extended mode (see <a href="extended-mode.html#extended-mode">extended mode</a>). |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">E </span><var>nn</var></samp>’<dd>for an error |
| <br><dt>‘<samp><span class="samp">Any stop packet</span></samp>’<dd>for success (see <a href="Stop-Reply-Packets.html#Stop-Reply-Packets">Stop Reply Packets</a>) |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">vStopped</span></samp>’<dd><a name="index-g_t_0040samp_007bvStopped_007d-packet-3467"></a>See <a href="Notification-Packets.html#Notification-Packets">Notification Packets</a>. |
| |
| <br><dt>‘<samp><span class="samp">X </span><var>addr</var><span class="samp">,</span><var>length</var><span class="samp">:</span><var>XX<small class="dots">...</small></var></samp>’<dd><a name="X-packet"></a><a name="index-g_t_0040samp_007bX_007d-packet-3468"></a>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="addressable-memory-unit.html#addressable-memory-unit">addressable memory unit</a>); |
| ‘<samp><var>XX</var><span class="samp">...</span></samp>’ is binary data (see <a href="Binary-Data.html#Binary-Data">Binary Data</a>). |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>for success |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">z </span><var>type</var><span class="samp">,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dt>‘<samp><span class="samp">Z </span><var>type</var><span class="samp">,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dd><a name="insert-breakpoint-or-watchpoint-packet"></a><a name="index-g_t_0040samp_007bz_007d-packet-3469"></a><a name="index-g_t_0040samp_007bZ_007d-packets-3470"></a>Insert (‘<samp><span class="samp">Z</span></samp>’) or remove (‘<samp><span class="samp">z</span></samp>’) a <var>type</var> breakpoint or |
| watchpoint starting at address <var>address</var> of kind <var>kind</var>. |
| |
| <p>Each breakpoint and watchpoint packet <var>type</var> is documented |
| separately. |
| |
| <p><em>Implementation notes: A remote target shall return an empty string |
| for an unrecognized breakpoint or watchpoint packet </em><var>type</var><em>. A |
| remote target shall support either both or neither of a given |
| ‘</em><samp><span class="samp">Z</span><var>type</var><span class="samp">...</span></samp><em>’ and ‘</em><samp><span class="samp">z</span><var>type</var><span class="samp">...</span></samp><em>’ packet pair. To |
| avoid potential problems with duplicate packets, the operations should |
| be implemented in an idempotent way.</em> |
| |
| <br><dt>‘<samp><span class="samp">z0,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dt>‘<samp><span class="samp">Z0,</span><var>addr</var><span class="samp">,</span><var>kind</var><span class="samp">[;</span><var>cond_list</var><span class="samp">...][;cmds:</span><var>persist</var><span class="samp">,</span><var>cmd_list</var><span class="samp">...]</span></samp>’<dd><a name="index-g_t_0040samp_007bz0_007d-packet-3471"></a><a name="index-g_t_0040samp_007bZ0_007d-packet-3472"></a>Insert (‘<samp><span class="samp">Z0</span></samp>’) or remove (‘<samp><span class="samp">z0</span></samp>’) a software breakpoint at address |
| <var>addr</var> of type <var>kind</var>. |
| |
| <p>A software 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 <span class="sc">arm</span> and |
| <span class="sc">mips</span> can insert either a 2 or 4 byte breakpoint. Some |
| architectures have additional meanings for <var>kind</var> |
| (see <a href="Architecture_002dSpecific-Protocol-Details.html#Architecture_002dSpecific-Protocol-Details">Architecture-Specific Protocol Details</a>); if no |
| architecture-specific value is being used, it should be ‘<samp><span class="samp">0</span></samp>’. |
| <var>kind</var> is hex-encoded. <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 <span class="sc">gdb</span>. |
| |
| <p>See also the ‘<samp><span class="samp">swbreak</span></samp>’ stop reason (see <a href="swbreak-stop-reason.html#swbreak-stop-reason">swbreak stop reason</a>) |
| for how to best report a software breakpoint event to <span class="sc">gdb</span>. |
| |
| <p>The <var>cond_list</var> parameter is comprised of a series of expressions, |
| concatenated without separators. Each expression has the following form: |
| |
| <dl> |
| <dt>‘<samp><span class="samp">X </span><var>len</var><span class="samp">,</span><var>expr</var></samp>’<dd><var>len</var> is the length of the bytecode expression and <var>expr</var> is the |
| actual conditional expression in bytecode form. |
| |
| </dl> |
| |
| <p>The optional <var>cmd_list</var> parameter introduces commands that may be |
| run on the target, rather than being reported back to <span class="sc">gdb</span>. |
| 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 <span class="sc">gdb</span> disconnects from the target. |
| Following this flag is a series of expressions concatenated with no |
| separators. Each expression has the following form: |
| |
| <dl> |
| <dt>‘<samp><span class="samp">X </span><var>len</var><span class="samp">,</span><var>expr</var></samp>’<dd><var>len</var> is the length of the bytecode expression and <var>expr</var> is the |
| actual commands expression in bytecode form. |
| |
| </dl> |
| |
| <p><em>Implementation note: It is possible for a target to copy or move |
| code that contains software breakpoints (e.g., when implementing |
| overlays). The behavior of this packet, in the presence of such a |
| target, is not defined.</em> |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>success |
| <br><dt>‘<samp><span class="samp"><!-- /@w --></span></samp>’<dd>not supported |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">z1,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dt>‘<samp><span class="samp">Z1,</span><var>addr</var><span class="samp">,</span><var>kind</var><span class="samp">[;</span><var>cond_list</var><span class="samp">...][;cmds:</span><var>persist</var><span class="samp">,</span><var>cmd_list</var><span class="samp">...]</span></samp>’<dd><a name="index-g_t_0040samp_007bz1_007d-packet-3473"></a><a name="index-g_t_0040samp_007bZ1_007d-packet-3474"></a>Insert (‘<samp><span class="samp">Z1</span></samp>’) or remove (‘<samp><span class="samp">z1</span></samp>’) a hardware breakpoint at |
| address <var>addr</var>. |
| |
| <p>A hardware breakpoint is implemented using a mechanism that is not |
| dependent on being able to modify the target's memory. The |
| <var>kind</var>, <var>cond_list</var>, and <var>cmd_list</var> arguments have the |
| same meaning as in ‘<samp><span class="samp">Z0</span></samp>’ packets. |
| |
| <p><em>Implementation note: A hardware breakpoint is not affected by code |
| movement.</em> |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>success |
| <br><dt>‘<samp><span class="samp"><!-- /@w --></span></samp>’<dd>not supported |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">z2,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dt>‘<samp><span class="samp">Z2,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dd><a name="index-g_t_0040samp_007bz2_007d-packet-3475"></a><a name="index-g_t_0040samp_007bZ2_007d-packet-3476"></a>Insert (‘<samp><span class="samp">Z2</span></samp>’) or remove (‘<samp><span class="samp">z2</span></samp>’) a write watchpoint at <var>addr</var>. |
| The number of bytes to watch is specified by <var>kind</var>. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>success |
| <br><dt>‘<samp><span class="samp"><!-- /@w --></span></samp>’<dd>not supported |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">z3,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dt>‘<samp><span class="samp">Z3,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dd><a name="index-g_t_0040samp_007bz3_007d-packet-3477"></a><a name="index-g_t_0040samp_007bZ3_007d-packet-3478"></a>Insert (‘<samp><span class="samp">Z3</span></samp>’) or remove (‘<samp><span class="samp">z3</span></samp>’) a read watchpoint at <var>addr</var>. |
| The number of bytes to watch is specified by <var>kind</var>. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>success |
| <br><dt>‘<samp><span class="samp"><!-- /@w --></span></samp>’<dd>not supported |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| <br><dt>‘<samp><span class="samp">z4,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dt>‘<samp><span class="samp">Z4,</span><var>addr</var><span class="samp">,</span><var>kind</var></samp>’<dd><a name="index-g_t_0040samp_007bz4_007d-packet-3479"></a><a name="index-g_t_0040samp_007bZ4_007d-packet-3480"></a>Insert (‘<samp><span class="samp">Z4</span></samp>’) or remove (‘<samp><span class="samp">z4</span></samp>’) an access watchpoint at <var>addr</var>. |
| The number of bytes to watch is specified by <var>kind</var>. |
| |
| <p>Reply: |
| <dl> |
| <dt>‘<samp><span class="samp">OK</span></samp>’<dd>success |
| <br><dt>‘<samp><span class="samp"><!-- /@w --></span></samp>’<dd>not supported |
| <br><dt>‘<samp><span class="samp">E </span><var>NN</var></samp>’<dd>for an error |
| </dl> |
| |
| </dl> |
| |
| </body></html> |
| |
