| 123 | === Running code === |
| 124 | |
| 125 | The following rules apply: |
| 126 | |
| 127 | * All the managed processors are frozen at the same time when the gdb client prompt is displayed. |
| 128 | * When using the `continue` command, all processors resume at the same time. |
| 129 | * Single step execution is '''only''' performed on the processor which was interrupted. User selection of a different processor for data examination with the `thread` command does '''not''' change this. (see advanced commands section below) |
| 130 | |
| 131 | === Advanced commands === |
| 132 | |
| 133 | The gdb client offers a easy way to send server specific data though the `monitor` command. Our GdbServer takes advantages of the `monitor` command to provide useful advanced features: |
| 134 | |
| 135 | * The processor (thread id) used for step by step execution may be forced for the next '''single step''' operation: |
| 136 | {{{(gdb) monitor stepcpu 1}}} |
| 137 | * The GdbServer may be instructed to break on processor exception or to let the processor jump in its exception handler transparently. When used with an extra parameter, this setting can apply to a single processor instead of all. The following command enable exception catching for thread id 2 (processor 1): |
| 138 | {{{(gdb) monitor except 1 2}}} |
| 139 | * The gdb protocol debug mode may enabled to dump interaction between client and server: |
| 140 | {{{(gdb) monitor debug 1}}} |
| 141 | |