Services - tools - models - for embedded software development
Embecosm divider strip
Prev  Next

3.2.1.  The target remote Command

The RSP packet exchanges to implement the GDB target remote command are shown as a sequence diagram in Figure 3.1.

RSP packet exchanges for the GDB target remote command

Figure 3.1.  RSP packet exchanges for the GDB target remote command


This is the initial dialog once the connection has been established. The first thing the client needs to know is what this RSP server supports. The only feature that matters is to report the packet size that is supported. The largest packet that will be needed is to hold a command with the hexadecimal values of all the general registers (for the G packets). In this example, there are a total of 35 32-bit registers, each requiring 8 hex characters + 1 character for the 'G', a total of 281 (hexadecimal 0x119) characters.

The client then asks why the target halted. For a standard remote connection (rather than extended remote connection), the target must be running, even if it has halted for a signal. So the client will verify that the reply is not W (exited) or X (terminated with signal). In this case the target reports it has stopped due to a TRAP exception.

The next packet is an instruction from the client that any future step or continue commands should apply to all threads. This is followed by a request (qC) for information on the thread currently running. In this example the target is "bare metal", so there is no concept of threads. An empty response is interpreted as "use the existing value", which suits in this case—since it is never set explicitly, it will be the NULL thread ID, which is appropriate.

The next packet (qOffsets) requests any offsets for loading binary data. At the minimum this must return offsets for the text, data and BSS sections of an executable—in this example all zero.

[Note]Note

The BSS component must be specified, contrary to the advice in the GDB User Guide.

The client then fetches the value of all the registers, so it can populate its register cache. It first specifies that operations such as these apply to all threads (Hg-1 packet), then requests the value of all registers (g packet).

Finally the client offers to supply any symbolic data required by the server. In this example, no data is needed, so a reply of "OK" is sent.

Through this exchange, the GDB client shows the following output:

(gdb) target remote :51000
Remote debugging using :51000
0x00000100 in _start ()
(gdb)
	
Embecosm divider strip