4.7.9. Query Packets

Query packets all start with q. The functionality is all provided in the function rsp_query ().

4.7.9.1. Deprecated Query Packets

The qL and qP packets to obtain information about threads are now obsolete, and are ignored with a warning. An empty reply (meaning not supported) is sent to each.

These packets have been replaced by qC, qfThreadInfo, qsThreadInfo, qThreadExtraInfo and qGetTLSAddr packets (see Section 4.7.9.3).

4.7.9.2. Unsupported Query Packets

A number of query packets are not needed in an initial implementation, or make no sense for a "bare metal" target.

qCRC. This can be implemented later by writing the code to compute a CRC for a memory area. A warning is printed and an error packet ("E01") returned.
qGetTLSAddr. This is a highly operating system dependent function to return the location of thread local storage. It has no meaning in a simple "bare metal" target. An empty reply is used to indicate that the feature is not supported.
qRcmd. This packet is used to run a remote command. Although this does not have a direct meaning, it is a useful way of passing arbitrary requests to the target. In the current implementation two commands readspr and writespr are provided to read and write values from and to Special Purpose Registers (needed for the GDB info spr and spr commands). These commands cannot be implemented using the main packets, since SPRs do not appear in either the memory map or the register file.
A side effect of this mechanism is that the remote commands are directly visible to the user through the GDB monitor command. Thus there are two ways to view a SPR. The "official" way:
```
(gdb) info spr npc
SYS.NPC = SPR0_16 = 256 (0x100)
(gdb) 
	      
```
And the unofficial way:
```
(gdb) monitor readspr 10
     100(gdb)
	      
```
For this reason, defining and using a new qXfer packet type (see below) might be preferred as a way of accessing custom information such as SPR values.
qXfer:. This packet is used to transfer "special" data to and from the target. A number of variants are already defined, to access particular features, some specific to certain targets and operating systems.
This is the alternative way to provide SPR access, by providing a new variant qXfer specific to the OpenRISC 1000. However any new qXfer does demand integration within GDB.
qXfer functionality must be specifically enabled using the qSupported packet (see Section 4.7.9.5). For the present this is not provided.

4.7.9.3. Queries About Threads

Although threads are not meaningful on the "bare metal" target, sensible replies can be given to most of the thread related queries by using -1 to mean "all threads".

qC. An empty reply is used, which is interpreted as "use the previously selected thread". Since no thread is ever explicitly selected by the target, this will allow the client GDB session to use its default NULL thread, which is what is wanted.
qfThreadInfo and qsThreadInfo. These packets are used to report the currently active threads. qfThreadInfo is used to report the first set of information and qsThreadInfo for all subsequent information, until a reply packet of "l" indicates the last packet.
In this implementation, a reply packet of "m-1" (all packets are active is used for qfThreadInfo and a reply packet of "l" is used for qsThreadInfo to indicate there is no more information.
qThreadExtraInfo. This should return a printed string, encoded as ASCII characters as hexadecimal digits with attributes of the thread specified as argument.
The argument is always ignored (this target only has one thread), and the reply "Runnable" is sent back

4.7.9.4. Query About Executable Relocation

The qOffsets packet requests a reply string of the format "Text=xx;Data=yy;Bss=zz" to identify the offsets used in relocating the sections of code to be downloaded.

No relocation is used in this target, so the fixed string "Text=0;Data=0;Bss=0" is sent as a reply.

	Caution
	The GDB User Guide ([3]) suggests the final `";Bss=zz"` is optional. This is not the case. It must be specified.

4.7.9.5. Query About Supported Functionality

The qSupported packet asks the client for information about features for which support is optional. By default, none are supported. The features are maximum packet size and support for the various qXfer packets and the QPassSignals packet.

Of these only the packet size is of relevance to this target, so a reply of "PacketSize=xx", where "xx" is the maximum packet size (GDB_BUF_MAX) is sent.

4.7.9.6. Query About Symbol Table Data

A qSymbol:: packet (i.e. a qSymbol packet with no data) is used as an offer from the client to provide symbol table information. The server may respond with packets of the form qSymbol:name to request information about the symbol name.

A reply of "OK" is used to indicate that no further symbol table information is required. For the current implementation, no information is required, so "OK" is always sent as the response.