command qSupported

Format: ‘qSupported [:gdbfeature [;gdbfeature]… ]’

Meaning: Tell the remote stub about features supported by GDB, and query the stub for features it supports. This packet allows GDB and the remote stub to take advantage of each others’ features. ‘qSupported’ also consolidates multiple feature probes at startup, to improve GDB performance—a single larger packet performs better than multiple smaller probe packets on high-latency links. Some features may enable behavior which must not be on by default, e.g. because it would confuse older clients or stubs. Other features may describe packets which could be automatically probed for, but are not. These features must be reported before GDB will use them. This “default unsupported” behavior is not appropriate for all packets, but it helps to keep the initial connection time under control with new versions of GDB which support increasing numbers of packets.

The allowed forms for each feature (either a gdbfeature in the ‘qSupported’ packet, or a stubfeature in the response) are:

• ‘name=value’ The remote protocol feature name is supported, and associated with the specified value. The format of value depends on the feature, but it must not include a semicolon.
• ‘name+’ The remote protocol feature name is supported, and does not need an associated value.
• ‘name-’ The remote protocol feature name is not supported.
• ‘name?’ The remote protocol feature name may be supported, and GDB should auto-detect support in some other way when it is needed. This form will not be used for gdbfeature notifications, but may be used for stubfeature responses.

Whenever the stub receives a ‘qSupported’ request, the supplied set of GDB features should override any previous request. This allows GDB to put the stub in a known state, even if the stub had previously been communicating with a different version of GDB.

The following values of gdbfeature (for the packet sent by GDB) are defined:

• ‘multiprocess’ This feature indicates whether GDB supports multiprocess extensions to the remote protocol. GDB does not use such extensions unless the stub also reports that it supports them by including ‘multiprocess+’ in its ‘qSupported’ reply. See multiprocess extensions, for details.
• ‘xmlRegisters’ This feature indicates that GDB supports the XML target description. If the stub sees ‘xmlRegisters=’ with target specific strings separated by a comma, it will report register description.
• ‘qRelocInsn’ This feature indicates whether GDB supports the ‘qRelocInsn’ packet (see Relocate instruction reply packet).
• ‘swbreak’ This feature indicates whether GDB supports the swbreak stop reason in stop replies. See swbreak stop reason, for details.
• ‘hwbreak’ This feature indicates whether GDB supports the hwbreak stop reason in stop replies. See swbreak stop reason, for details.
• ‘fork-events’ This feature indicates whether GDB supports fork event extensions to the remote protocol. GDB does not use such extensions unless the stub also reports that it supports them by including ‘fork-events+’ in its ‘qSupported’ reply.
• ‘vfork-events’ This feature indicates whether GDB supports vfork event extensions to the remote protocol. GDB does not use such extensions unless the stub also reports that it supports them by including ‘vfork-events+’ in its ‘qSupported’ reply.
• ‘exec-events’ This feature indicates whether GDB supports exec event extensions to the remote protocol. GDB does not use such extensions unless the stub also reports that it supports them by including ‘exec-events+’ in its ‘qSupported’ reply.
• ‘vContSupported’ This feature indicates whether GDB wants to know the supported actions in the reply to ‘vCont?’ packet.
• ‘error-message’ This feature indicates whether GDB supports accepting a reply in ‘E.errtext’ format (See textual error reply) from the ‘qRcmd’ and ‘m’ packets. These packets, historically, didn’t support ‘E.errtext’, and older versions of GDB didn’t expect to see a reply in this format. New packets should be written to support ‘E.errtext’ regardless of this feature being true or not.

Stubs should ignore any unknown values for gdbfeature. Any GDB which sends a ‘qSupported’ packet supports receiving packets of unlimited length (earlier versions of GDB may reject overly long responses). Additional values for gdbfeature may be defined in the future to let the stub take advantage of new features in GDB, e.g. incompatible improvements in the remote protocol—the ‘multiprocess’ feature is an example of such a feature. The stub’s reply should be independent of the gdbfeature entries sent by GDB; first GDB describes all the features it supports, and then the stub replies with all the features it supports.

Similarly, GDB will silently ignore unrecognized stub feature responses, as long as each response uses one of the standard forms.

Some features are flags. A stub which supports a flag feature should respond with a ‘+’ form response. Other features require values, and the stub should respond with an ‘=’ form response.

Each feature has a default value, which GDB will use if ‘qSupported’ is not available or if the feature is not mentioned in the ‘qSupported’ response. The default values are fixed; a stub is free to omit any feature responses that match the defaults.

Not all features can be probed, but for those which can, the probing mechanism is useful: in some cases, a stub’s internal architecture may not allow the protocol layer to know some information about the underlying target in advance. This is especially common in stubs which may be configured for multiple targets.

These are the currently defined stub features and their properties:

These are the currently defined stub features, in more detail:

• ‘PacketSize=bytes’ The remote stub can accept packets up to at least bytes in length. GDB will send packets up to this size for bulk transfers, and will never send larger packets. This is a limit on the data characters in the packet, not including the frame and checksum. There is no trailing NUL byte in a remote protocol packet; if the stub stores packets in a NUL-terminated format, it should allow an extra byte in its buffer for the NUL. If this stub feature is not supported, GDB guesses based on the size of the ‘g’ packet response.
• ‘qXfer:auxv:read’ The remote stub understands the ‘qXfer:auxv:read’ command.
• ‘qXfer:btrace:read’ The remote stub understands the ‘qXfer:btrace:read’ command.
• ‘qXfer:btrace-conf:read’ The remote stub understands the ‘qXfer:btrace-conf:read’ command.
• ‘qXfer:exec-file:read’ The remote stub understands the ‘qXfer:exec-file:read’ command.
• ‘qXfer:features:read’ The remote stub understands the ‘qXfer:features:read’ command.
• ‘qXfer:libraries:read’ The remote stub understands the ‘qXfer:libraries:read’ command.
• ‘qXfer:libraries-svr4:read’ The remote stub understands the ‘qXfer:libraries-svr4:read’ command.
• ‘augmented-libraries-svr4-read’ The remote stub understands the augmented form of the ‘qXfer:libraries-svr4:read’ command.
• ‘qXfer:memory-map:read’ The remote stub understands the ‘qXfer:memory-map:read’ command.
• ‘qXfer:sdata:read’ The remote stub understands the ‘qXfer:sdata:read’ command.
• ‘qXfer:siginfo:read’ The remote stub understands the ‘qXfer:siginfo:read’ command.
• ‘qXfer:siginfo:write’ The remote stub understands the ‘qXfer:siginfo:write’ command.
• ‘qXfer:threads:read’ The remote stub understands the ‘qXfer:threads:read’ command.
• ‘qXfer:traceframe-info:read’ The remote stub understands the ‘qXfer:traceframe-info:read’ command.
• ‘qXfer:uib:read’ The remote stub understands the ‘qXfer:uib:read’ command.
• ‘qXfer:fdpic:read’ The remote stub understands the ‘qXfer:fdpic:read’ command.
• ‘QNonStop’ The remote stub understands the ‘QNonStop’ command.
• ‘QCatchSyscalls’ The remote stub understands the ‘QCatchSyscalls’ command.
• ‘QPassSignals’ The remote stub understands the ‘QPassSignals’ command.
• ‘QStartNoAckMode’ The remote stub understands the ‘QStartNoAckMode’ packet and prefers to operate in no-acknowledgment mode. See Packet Acknowledgment.
• ‘multiprocess’ The remote stub understands the multiprocess extensions to the remote protocol syntax. The multiprocess extensions affect the syntax of thread IDs in both packets and replies (see thread-id syntax), and add process IDs to the ‘D’ packet and ‘W’ and ‘X’ replies. Note that reporting this feature indicates support for the syntactic extensions only, not that the stub necessarily supports debugging of more than one process at a time. The stub must not use multiprocess extensions in packet replies unless GDB has also indicated it supports them in its ‘qSupported’ request.
• ‘qXfer:osdata:read’ The remote stub understands the ‘qXfer:osdata:read’ command.
• ‘ConditionalBreakpoints’ The target accepts and implements evaluation of conditional expressions defined for breakpoints. The target will only report breakpoint triggers when such conditions are true (see Break Conditions).
• ‘ConditionalTracepoints’ The remote stub accepts and implements conditional expressions defined for tracepoints (see Tracepoint Conditions).
• ‘ReverseContinue’ The remote stub accepts and implements the reverse continue packet (see bc).
• ‘ReverseStep’ The remote stub accepts and implements the reverse step packet (see bs).
• ‘TracepointSource’ The remote stub understands the ‘QTDPsrc’ packet that supplies the source form of tracepoint definitions.
• ‘QAgent’ The remote stub understands the ‘QAgent’ packet.
• ‘QAllow’ The remote stub understands the ‘QAllow’ packet.
• ‘QDisableRandomization’ The remote stub understands the ‘QDisableRandomization’ packet.
• ‘StaticTracepoint’ The remote stub supports static tracepoints.
• ‘InstallInTrace’ The remote stub supports installing tracepoint in tracing.
• ‘EnableDisableTracepoints’ The remote stub supports the ‘QTEnable’ (see QTEnable) and ‘QTDisable’ (see QTDisable) packets that allow tracepoints to be enabled and disabled while a trace experiment is running.
• ‘QTBuffer:size’ The remote stub supports the ‘QTBuffer:size’ (see QTBuffer-size) packet that allows to change the size of the trace buffer.
• ‘tracenz’ The remote stub supports the ‘tracenz’ bytecode for collecting strings. See Bytecode Descriptions for details about the bytecode.
• ‘BreakpointCommands’ The remote stub supports running a breakpoint’s command list itself, rather than reporting the hit to GDB.
• ‘Qbtrace:off’ The remote stub understands the ‘Qbtrace:off’ packet.
• ‘Qbtrace:bts’ The remote stub understands the ‘Qbtrace:bts’ packet.
• ‘Qbtrace:pt’ The remote stub understands the ‘Qbtrace:pt’ packet.
• ‘Qbtrace-conf:bts:size’ The remote stub understands the ‘Qbtrace-conf:bts:size’ packet.
• ‘Qbtrace-conf:pt:size’ The remote stub understands the ‘Qbtrace-conf:pt:size’ packet.
• ‘Qbtrace-conf:pt:ptwrite’ The remote stub understands the ‘Qbtrace-conf:pt:ptwrite’ packet.
• ‘Qbtrace-conf:pt:event-tracing’ The remote stub understands the ‘Qbtrace-conf:pt:event-tracing’ packet.
• ‘swbreak’ The remote stub reports the ‘swbreak’ stop reason for memory breakpoints.
• ‘hwbreak’ The remote stub reports the ‘hwbreak’ stop reason for hardware breakpoints.
• ‘fork-events’ The remote stub reports the ‘fork’ stop reason for fork events.
• ‘vfork-events’ The remote stub reports the ‘vfork’ stop reason for vfork events and vforkdone events.
• ‘exec-events’ The remote stub reports the ‘exec’ stop reason for exec events.
• ‘vContSupported’ The remote stub reports the supported actions in the reply to ‘vCont?’ packet.
• ‘QThreadEvents’ The remote stub understands the ‘QThreadEvents’ packet.
• ‘QThreadOptions=supported_options’ The remote stub understands the ‘QThreadOptions’ packet. supported_options indicates the set of thread options the remote stub supports. Supported_options has the same format as the options parameter of the QThreadOptions packet, described at QThreadOptions.
• ‘no-resumed’ The remote stub reports the ‘N’ stop reply.
• ‘memory-tagging’ The remote stub supports and implements the required memory tagging functionality and understands the ‘qMemTags’ (see qMemTags) and ‘QMemTags’ (see QMemTags) packets. For AArch64 GNU/Linux systems, this feature can require access to the /proc/pid/smaps file so memory mapping page flags can be inspected, if ‘qIsAddressTagged’ (see qIsAddressTagged) packet is not supported by the stub. Access to the /proc/pid/smaps file is done via ‘vFile’ requests.
• ‘error-message’ The remote stub supports replying with an error in a ‘E.errtext’ (See textual error reply) format from the ‘m’ and ‘qRcmd’ packets. It is not usually necessary to send this feature back to GDB in the ‘qSupported’ reply, GDB will always support ‘E.errtext’ format replies if it sent the ‘error-message’ feature.
• ‘binary-upload’ The remote stub supports the ‘x’ packet (see x packet).

Reply:

stubfeature [;stubfeature]…

The stub supports or does not support each returned stubfeature, depending on the form of each stubfeature.