gdb.info: General Query Packets

Go forward to Register Packet Format
Go backward to Stop Reply Packets
Go up to Remote Protocol
Go to the top op gdb

General Query Packets

The following set and query packets have already been defined.
`q'`C' -- current thread
     Return the current thread id.
     Reply:
    ``QC'PID'
          Where PID is a HEX encoded 16 bit process id.
    `*'
          Any other reply implies the old pid.
`q'`fThreadInfo' - all thread ids
     `q'`sThreadInfo'
     Obtain a list of active thread ids from the target (OS).  Since
     there may be too many active threads to fit into one reply packet,
     this query works iteratively: it may require more than one
     query/reply sequence to obtain the entire list of threads.  The
     first query of the sequence will be the `qf'`ThreadInfo' query;
     subsequent queries in the sequence will be the `qs'`ThreadInfo'
     query.
     NOTE: replaces the `qL' query (see below).
     Reply:
    ``m'ID'
          A single thread id
    ``m'ID,ID...'
          a comma-separated list of thread ids
    ``l''
          (lower case 'el') denotes end of list.
     In response to each query, the target will reply with a list of
     one or more thread ids, in big-endian hex, separated by commas.
     GDB will respond to each reply with a request for more thread ids
     (using the `qs' form of the query), until the target responds with
     `l' (lower-case el, for `'last'').
`q'`ThreadExtraInfo'`,'ID -- extra thread info
     Where ID is a thread-id in big-endian hex.  Obtain a printable
     string description of a thread's attributes from the target OS.
     This string may contain anything that the target OS thinks is
     interesting for GDB to tell the user about the thread.  The string
     is displayed in GDB's `info threads' display.  Some examples of
     possible thread extra info strings are "Runnable", or "Blocked on
     Mutex".
     Reply:
    `XX...'
          Where XX... is a hex encoding of ASCII data, comprising the
          printable string containing the extra information about the
          thread's attributes.
`q'`L'STARTFLAGTHREADCOUNTNEXTTHREAD -- query LIST or THREADLIST *(deprecated)*
     Obtain thread information from RTOS.  Where: STARTFLAG (one hex
     digit) is one to indicate the first query and zero to indicate a
     subsequent query; THREADCOUNT (two hex digits) is the maximum
     number of threads the response packet can contain; and NEXTTHREAD
     (eight hex digits), for subsequent queries (STARTFLAG is zero), is
     returned in the response as ARGTHREAD.
     NOTE: this query is replaced by the `q'`fThreadInfo' query (see
     above).
     Reply:
    ``q'`M'COUNTDONEARGTHREADTHREAD...'
          Where: COUNT (two hex digits) is the number of threads being
          returned; DONE (one hex digit) is zero to indicate more
          threads and one indicates no further threads; ARGTHREADID
          (eight hex digits) is NEXTTHREAD from the request packet;
          THREAD...  is a sequence of thread IDs from the target.
          THREADID (eight hex digits).  See
          `remote.c:parse_threadlist_response()'.
`q'`CRC:'ADDR`,'LENGTH -- compute CRC of memory block
     Reply:
    ``E'NN'
          An error (such as memory fault)
    ``C'CRC32'
          A 32 bit cyclic redundancy check of the specified memory
          region.
`q'`Offsets' -- query sect offs
     Get section offsets that the target used when re-locating the
     downloaded image.  _Note: while a `Bss' offset is included in the
     response, GDB ignores this and instead applies the `Data' offset
     to the `Bss' section._
     Reply:
    ``Text='XXX`;Data='YYY`;Bss='ZZZ'
`q'`P'MODETHREADID -- thread info request
     Returns information on THREADID.  Where: MODE is a hex encoded 32
     bit mode; THREADID is a hex encoded 64 bit thread ID.

Reply: `*'

     See `remote.c:remote_unpack_thread_info_response()'.
`q'`Rcmd,'COMMAND -- remote command
     COMMAND (hex encoded) is passed to the local interpreter for
     execution.  Invalid commands should be reported using the output
     string.  Before the final result packet, the target may also
     respond with a number of intermediate `O'OUTPUT console output
     packets.  _Implementors should note that providing access to a
     stubs's interpreter may have security implications_.
     Reply:
    `OK'
          A command response with no output.
    `OUTPUT'
          A command response with the hex encoded output string OUTPUT.
    ``E'NN'
          Indicate a badly formed request.
    ``''
          When `q'`Rcmd' is not recognized.
`qSymbol::' -- symbol lookup
     Notify the target that GDB is prepared to serve symbol lookup
     requests.  Accept requests from the target for the values of
     symbols.
     Reply:
    ``OK''
          The target does not need to look up any (more) symbols.
    ``qSymbol:'SYM_NAME'
          The target requests the value of symbol SYM_NAME (hex
          encoded).  GDB may provide the value by using the
          `qSymbol:'SYM_VALUE:SYM_NAME message, described below.
`qSymbol:'SYM_VALUE:SYM_NAME -- symbol value
     Set the value of SYM_NAME to SYM_VALUE.
     SYM_NAME (hex encoded) is the name of a symbol whose value the
     target has previously requested.
     SYM_VALUE (hex) is the value for symbol SYM_NAME.  If GDB cannot
     supply a value for SYM_NAME, then this field will be empty.
     Reply:
    ``OK''
          The target does not need to look up any (more) symbols.
    ``qSymbol:'SYM_NAME'
          The target requests the value of a new symbol SYM_NAME (hex
          encoded).  GDB will continue to supply the values of symbols
          (if available), until the target ceases to request them.
`qPart':OBJECT:`read':ANNEX:OFFSET,LENGTH -- read special data
     Read uninterpreted bytes from the target's special data area
     identified by the keyword `object'.  Request LENGTH bytes starting
     at OFFSET bytes into the data.  The content and encoding of ANNEX
     is specific to the object; it can supply additional details about
     what data to access.
     Here are the specific requests of this form defined so far.  All
     ``qPart':OBJECT:`read':...' requests use the same reply formats,
     listed below.
    `qPart':`auxv':`read'::OFFSET,LENGTH
          Access the target's "auxiliary vector".  *Note Auxiliary
          Vector::.  Note ANNEX must be empty.
     Reply:
    `OK'
          The OFFSET in the request is at the end of the data.  There
          is no more data to be read.
    XX...
          Hex encoded data bytes read.  This may be fewer bytes than
          the LENGTH in the request.
    `E00'
          The request was malformed, or ANNEX was invalid.
    `E'NN
          The offset was invalid, or there was an error encountered
          reading the data.  NN is a hex-encoded `errno' value.
    `""' (empty)
          An empty reply indicates the OBJECT or ANNEX string was not
          recognized by the stub.
`qPart':OBJECT:`write':ANNEX:OFFSET:DATA...
     Write uninterpreted bytes into the target's special data area
     identified by the keyword `object', starting at OFFSET bytes into
     the data.  DATA... is the hex-encoded data to be written.  The
     content and encoding of ANNEX is specific to the object; it can
     supply additional details about what data to access.
     No requests of this form are presently in use.  This specification
     serves as a placeholder to document the common format that new
     specific request specifications ought to use.
     Reply:
    NN
          NN (hex encoded) is the number of bytes written.  This may be
          fewer bytes than supplied in the request.
    `E00'
          The request was malformed, or ANNEX was invalid.
    `E'NN
          The offset was invalid, or there was an error encountered
          writing the data.  NN is a hex-encoded `errno' value.
    `""' (empty)
          An empty reply indicates the OBJECT or ANNEX string was not
          recognized by the stub, or that the object does not support
          writing.
`qPart':OBJECT:OPERATION:...
     Requests of this form may be added in the future.  When a stub does
     not recognize the OBJECT keyword, or its support for OBJECT does
     not recognize the OPERATION keyword, the stub must respond with an
     empty packet.