| 1 |
106 |
markom |
This is ./gdb.info, produced by Makeinfo version 3.12f from gdb.texinfo.
|
| 2 |
|
|
|
| 3 |
|
|
INFO-DIR-SECTION Programming & development tools.
|
| 4 |
|
|
START-INFO-DIR-ENTRY
|
| 5 |
|
|
* Gdb: (gdb). The GNU debugger.
|
| 6 |
|
|
END-INFO-DIR-ENTRY
|
| 7 |
|
|
|
| 8 |
|
|
This file documents the GNU debugger GDB.
|
| 9 |
|
|
|
| 10 |
|
|
This is the Eighth Edition, March 2000, of `Debugging with GDB: the
|
| 11 |
|
|
GNU Source-Level Debugger' for GDB Version 5.0.
|
| 12 |
|
|
|
| 13 |
|
|
Copyright (C) 1988-2000 Free Software Foundation, Inc.
|
| 14 |
|
|
|
| 15 |
|
|
Permission is granted to make and distribute verbatim copies of this
|
| 16 |
|
|
manual provided the copyright notice and this permission notice are
|
| 17 |
|
|
preserved on all copies.
|
| 18 |
|
|
|
| 19 |
|
|
Permission is granted to copy and distribute modified versions of
|
| 20 |
|
|
this manual under the conditions for verbatim copying, provided also
|
| 21 |
|
|
that the entire resulting derived work is distributed under the terms
|
| 22 |
|
|
of a permission notice identical to this one.
|
| 23 |
|
|
|
| 24 |
|
|
Permission is granted to copy and distribute translations of this
|
| 25 |
|
|
manual into another language, under the above conditions for modified
|
| 26 |
|
|
versions.
|
| 27 |
|
|
|
| 28 |
|
|
|
| 29 |
|
|
File: gdb.info, Node: Bootstrapping, Next: Debug Session, Prev: Stub Contents, Up: Remote Serial
|
| 30 |
|
|
|
| 31 |
|
|
What you must do for the stub
|
| 32 |
|
|
.............................
|
| 33 |
|
|
|
| 34 |
|
|
The debugging stubs that come with GDB are set up for a particular
|
| 35 |
|
|
chip architecture, but they have no information about the rest of your
|
| 36 |
|
|
debugging target machine.
|
| 37 |
|
|
|
| 38 |
|
|
First of all you need to tell the stub how to communicate with the
|
| 39 |
|
|
serial port.
|
| 40 |
|
|
|
| 41 |
|
|
`int getDebugChar()'
|
| 42 |
|
|
Write this subroutine to read a single character from the serial
|
| 43 |
|
|
port. It may be identical to `getchar' for your target system; a
|
| 44 |
|
|
different name is used to allow you to distinguish the two if you
|
| 45 |
|
|
wish.
|
| 46 |
|
|
|
| 47 |
|
|
`void putDebugChar(int)'
|
| 48 |
|
|
Write this subroutine to write a single character to the serial
|
| 49 |
|
|
port. It may be identical to `putchar' for your target system; a
|
| 50 |
|
|
different name is used to allow you to distinguish the two if you
|
| 51 |
|
|
wish.
|
| 52 |
|
|
|
| 53 |
|
|
If you want GDB to be able to stop your program while it is running,
|
| 54 |
|
|
you need to use an interrupt-driven serial driver, and arrange for it
|
| 55 |
|
|
to stop when it receives a `^C' (`\003', the control-C character).
|
| 56 |
|
|
That is the character which GDB uses to tell the remote system to stop.
|
| 57 |
|
|
|
| 58 |
|
|
Getting the debugging target to return the proper status to GDB
|
| 59 |
|
|
probably requires changes to the standard stub; one quick and dirty way
|
| 60 |
|
|
is to just execute a breakpoint instruction (the "dirty" part is that
|
| 61 |
|
|
GDB reports a `SIGTRAP' instead of a `SIGINT').
|
| 62 |
|
|
|
| 63 |
|
|
Other routines you need to supply are:
|
| 64 |
|
|
|
| 65 |
|
|
`void exceptionHandler (int EXCEPTION_NUMBER, void *EXCEPTION_ADDRESS)'
|
| 66 |
|
|
Write this function to install EXCEPTION_ADDRESS in the exception
|
| 67 |
|
|
handling tables. You need to do this because the stub does not
|
| 68 |
|
|
have any way of knowing what the exception handling tables on your
|
| 69 |
|
|
target system are like (for example, the processor's table might
|
| 70 |
|
|
be in ROM, containing entries which point to a table in RAM).
|
| 71 |
|
|
EXCEPTION_NUMBER is the exception number which should be changed;
|
| 72 |
|
|
its meaning is architecture-dependent (for example, different
|
| 73 |
|
|
numbers might represent divide by zero, misaligned access, etc).
|
| 74 |
|
|
When this exception occurs, control should be transferred directly
|
| 75 |
|
|
to EXCEPTION_ADDRESS, and the processor state (stack, registers,
|
| 76 |
|
|
and so on) should be just as it is when a processor exception
|
| 77 |
|
|
occurs. So if you want to use a jump instruction to reach
|
| 78 |
|
|
EXCEPTION_ADDRESS, it should be a simple jump, not a jump to
|
| 79 |
|
|
subroutine.
|
| 80 |
|
|
|
| 81 |
|
|
For the 386, EXCEPTION_ADDRESS should be installed as an interrupt
|
| 82 |
|
|
gate so that interrupts are masked while the handler runs. The
|
| 83 |
|
|
gate should be at privilege level 0 (the most privileged level).
|
| 84 |
|
|
The SPARC and 68k stubs are able to mask interrupts themselves
|
| 85 |
|
|
without help from `exceptionHandler'.
|
| 86 |
|
|
|
| 87 |
|
|
`void flush_i_cache()'
|
| 88 |
|
|
On SPARC and SPARCLITE only, write this subroutine to flush the
|
| 89 |
|
|
instruction cache, if any, on your target machine. If there is no
|
| 90 |
|
|
instruction cache, this subroutine may be a no-op.
|
| 91 |
|
|
|
| 92 |
|
|
On target machines that have instruction caches, GDB requires this
|
| 93 |
|
|
function to make certain that the state of your program is stable.
|
| 94 |
|
|
|
| 95 |
|
|
You must also make sure this library routine is available:
|
| 96 |
|
|
|
| 97 |
|
|
`void *memset(void *, int, int)'
|
| 98 |
|
|
This is the standard library function `memset' that sets an area of
|
| 99 |
|
|
memory to a known value. If you have one of the free versions of
|
| 100 |
|
|
`libc.a', `memset' can be found there; otherwise, you must either
|
| 101 |
|
|
obtain it from your hardware manufacturer, or write your own.
|
| 102 |
|
|
|
| 103 |
|
|
If you do not use the GNU C compiler, you may need other standard
|
| 104 |
|
|
library subroutines as well; this varies from one stub to another, but
|
| 105 |
|
|
in general the stubs are likely to use any of the common library
|
| 106 |
|
|
subroutines which `gcc' generates as inline code.
|
| 107 |
|
|
|
| 108 |
|
|
|
| 109 |
|
|
File: gdb.info, Node: Debug Session, Next: Protocol, Prev: Bootstrapping, Up: Remote Serial
|
| 110 |
|
|
|
| 111 |
|
|
Putting it all together
|
| 112 |
|
|
.......................
|
| 113 |
|
|
|
| 114 |
|
|
In summary, when your program is ready to debug, you must follow
|
| 115 |
|
|
these steps.
|
| 116 |
|
|
|
| 117 |
|
|
1. Make sure you have defined the supporting low-level routines
|
| 118 |
|
|
(*note What you must do for the stub: Bootstrapping.):
|
| 119 |
|
|
`getDebugChar', `putDebugChar',
|
| 120 |
|
|
`flush_i_cache', `memset', `exceptionHandler'.
|
| 121 |
|
|
|
| 122 |
|
|
2. Insert these lines near the top of your program:
|
| 123 |
|
|
|
| 124 |
|
|
set_debug_traps();
|
| 125 |
|
|
breakpoint();
|
| 126 |
|
|
|
| 127 |
|
|
3. For the 680x0 stub only, you need to provide a variable called
|
| 128 |
|
|
`exceptionHook'. Normally you just use:
|
| 129 |
|
|
|
| 130 |
|
|
void (*exceptionHook)() = 0;
|
| 131 |
|
|
|
| 132 |
|
|
but if before calling `set_debug_traps', you set it to point to a
|
| 133 |
|
|
function in your program, that function is called when `GDB'
|
| 134 |
|
|
continues after stopping on a trap (for example, bus error). The
|
| 135 |
|
|
function indicated by `exceptionHook' is called with one
|
| 136 |
|
|
parameter: an `int' which is the exception number.
|
| 137 |
|
|
|
| 138 |
|
|
4. Compile and link together: your program, the GDB debugging stub for
|
| 139 |
|
|
your target architecture, and the supporting subroutines.
|
| 140 |
|
|
|
| 141 |
|
|
5. Make sure you have a serial connection between your target machine
|
| 142 |
|
|
and the GDB host, and identify the serial port on the host.
|
| 143 |
|
|
|
| 144 |
|
|
6. Download your program to your target machine (or get it there by
|
| 145 |
|
|
whatever means the manufacturer provides), and start it.
|
| 146 |
|
|
|
| 147 |
|
|
7. To start remote debugging, run GDB on the host machine, and specify
|
| 148 |
|
|
as an executable file the program that is running in the remote
|
| 149 |
|
|
machine. This tells GDB how to find your program's symbols and
|
| 150 |
|
|
the contents of its pure text.
|
| 151 |
|
|
|
| 152 |
|
|
8. Establish communication using the `target remote' command. Its
|
| 153 |
|
|
argument specifies how to communicate with the target
|
| 154 |
|
|
machine--either via a devicename attached to a direct serial line,
|
| 155 |
|
|
or a TCP port (usually to a terminal server which in turn has a
|
| 156 |
|
|
serial line to the target). For example, to use a serial line
|
| 157 |
|
|
connected to the device named `/dev/ttyb':
|
| 158 |
|
|
|
| 159 |
|
|
target remote /dev/ttyb
|
| 160 |
|
|
|
| 161 |
|
|
To use a TCP connection, use an argument of the form `HOST:port'.
|
| 162 |
|
|
For example, to connect to port 2828 on a terminal server named
|
| 163 |
|
|
`manyfarms':
|
| 164 |
|
|
|
| 165 |
|
|
target remote manyfarms:2828
|
| 166 |
|
|
|
| 167 |
|
|
Now you can use all the usual commands to examine and change data
|
| 168 |
|
|
and to step and continue the remote program.
|
| 169 |
|
|
|
| 170 |
|
|
To resume the remote program and stop debugging it, use the `detach'
|
| 171 |
|
|
command.
|
| 172 |
|
|
|
| 173 |
|
|
Whenever GDB is waiting for the remote program, if you type the
|
| 174 |
|
|
interrupt character (often ), GDB attempts to stop the program.
|
| 175 |
|
|
This may or may not succeed, depending in part on the hardware and the
|
| 176 |
|
|
serial drivers the remote system uses. If you type the interrupt
|
| 177 |
|
|
character once again, GDB displays this prompt:
|
| 178 |
|
|
|
| 179 |
|
|
Interrupted while waiting for the program.
|
| 180 |
|
|
Give up (and stop debugging it)? (y or n)
|
| 181 |
|
|
|
| 182 |
|
|
If you type `y', GDB abandons the remote debugging session. (If you
|
| 183 |
|
|
decide you want to try again later, you can use `target remote' again
|
| 184 |
|
|
to connect once more.) If you type `n', GDB goes back to waiting.
|
| 185 |
|
|
|
| 186 |
|
|
|
| 187 |
|
|
File: gdb.info, Node: Protocol, Next: Server, Prev: Debug Session, Up: Remote Serial
|
| 188 |
|
|
|
| 189 |
|
|
Communication protocol
|
| 190 |
|
|
......................
|
| 191 |
|
|
|
| 192 |
|
|
The stub files provided with GDB implement the target side of the
|
| 193 |
|
|
communication protocol, and the GDB side is implemented in the GDB
|
| 194 |
|
|
source file `remote.c'. Normally, you can simply allow these
|
| 195 |
|
|
subroutines to communicate, and ignore the details. (If you're
|
| 196 |
|
|
implementing your own stub file, you can still ignore the details: start
|
| 197 |
|
|
with one of the existing stub files. `sparc-stub.c' is the best
|
| 198 |
|
|
organized, and therefore the easiest to read.)
|
| 199 |
|
|
|
| 200 |
|
|
However, there may be occasions when you need to know something about
|
| 201 |
|
|
the protocol--for example, if there is only one serial port to your
|
| 202 |
|
|
target machine, you might want your program to do something special if
|
| 203 |
|
|
it recognizes a packet meant for GDB.
|
| 204 |
|
|
|
| 205 |
|
|
In the examples below, `<-' and `->' are used to indicate
|
| 206 |
|
|
transmitted and received data respectfully.
|
| 207 |
|
|
|
| 208 |
|
|
All GDB commands and responses (other than acknowledgments) are sent
|
| 209 |
|
|
as a PACKET. A PACKET is introduced with the character `$', the actual
|
| 210 |
|
|
PACKET-DATA, and the terminating character `#' followed by a two-digit
|
| 211 |
|
|
CHECKSUM:
|
| 212 |
|
|
|
| 213 |
|
|
`$'PACKET-DATA`#'CHECKSUM
|
| 214 |
|
|
|
| 215 |
|
|
The two-digit CHECKSUM is computed as the modulo 256 sum of all
|
| 216 |
|
|
characters between the leading `$' and the trailing `#' (an eight bit
|
| 217 |
|
|
unsigned checksum).
|
| 218 |
|
|
|
| 219 |
|
|
Implementors should note that prior to GDB 5.0 the protocol
|
| 220 |
|
|
specification also included an optional two-digit SEQUENCE-ID:
|
| 221 |
|
|
|
| 222 |
|
|
`$'SEQUENCE-ID`:'PACKET-DATA`#'CHECKSUM
|
| 223 |
|
|
|
| 224 |
|
|
That SEQUENCE-ID was appended to the acknowledgment. GDB has never
|
| 225 |
|
|
output SEQUENCE-IDs. Stubs that handle packets added since GDB 5.0
|
| 226 |
|
|
must not accept SEQUENCE-ID.
|
| 227 |
|
|
|
| 228 |
|
|
When either the host or the target machine receives a packet, the
|
| 229 |
|
|
first response expected is an acknowledgment: either `+' (to indicate
|
| 230 |
|
|
the package was received correctly) or `-' (to request retransmission):
|
| 231 |
|
|
|
| 232 |
|
|
<- `$'PACKET-DATA`#'CHECKSUM
|
| 233 |
|
|
-> `+'
|
| 234 |
|
|
|
| 235 |
|
|
The host (GDB) sends COMMANDs, and the target (the debugging stub
|
| 236 |
|
|
incorporated in your program) sends a RESPONSE. In the case of step
|
| 237 |
|
|
and continue COMMANDs, the response is only sent when the operation has
|
| 238 |
|
|
completed (the target has again stopped).
|
| 239 |
|
|
|
| 240 |
|
|
PACKET-DATA consists of a sequence of characters with the exception
|
| 241 |
|
|
of `#' and `$' (see `X' packet for additional exceptions).
|
| 242 |
|
|
|
| 243 |
|
|
Fields within the packet should be separated using `,' `;' or `:'.
|
| 244 |
|
|
Except where otherwise noted all numbers are represented in HEX with
|
| 245 |
|
|
leading zeros suppressed.
|
| 246 |
|
|
|
| 247 |
|
|
Implementors should note that prior to GDB 5.0, the character `:'
|
| 248 |
|
|
could not appear as the third character in a packet (as it would
|
| 249 |
|
|
potentially conflict with the SEQUENCE-ID).
|
| 250 |
|
|
|
| 251 |
|
|
Response DATA can be run-length encoded to save space. A `*' means
|
| 252 |
|
|
that the next character is an ASCII encoding giving a repeat count
|
| 253 |
|
|
which stands for that many repetitions of the character preceding the
|
| 254 |
|
|
`*'. The encoding is `n+29', yielding a printable character where `n
|
| 255 |
|
|
>=3' (which is where rle starts to win). The printable characters `$',
|
| 256 |
|
|
`#', `+' and `-' or with a numeric value greater than 126 should not be
|
| 257 |
|
|
used.
|
| 258 |
|
|
|
| 259 |
|
|
Some remote systems have used a different run-length encoding
|
| 260 |
|
|
mechanism loosely refered to as the cisco encoding. Following the `*'
|
| 261 |
|
|
character are two hex digits that indicate the size of the packet.
|
| 262 |
|
|
|
| 263 |
|
|
So:
|
| 264 |
|
|
"`0* '"
|
| 265 |
|
|
|
| 266 |
|
|
means the same as "0000".
|
| 267 |
|
|
|
| 268 |
|
|
The error response returned for some packets includes a two character
|
| 269 |
|
|
error number. That number is not well defined.
|
| 270 |
|
|
|
| 271 |
|
|
For any COMMAND not supported by the stub, an empty response
|
| 272 |
|
|
(`$#00') should be returned. That way it is possible to extend the
|
| 273 |
|
|
protocol. A newer GDB can tell if a packet is supported based on that
|
| 274 |
|
|
response.
|
| 275 |
|
|
|
| 276 |
|
|
A stub is required to support the `g', `G', `m', `M', `c', and `s'
|
| 277 |
|
|
COMMANDs. All other COMMANDs are optional.
|
| 278 |
|
|
|
| 279 |
|
|
Below is a complete list of all currently defined COMMANDs and their
|
| 280 |
|
|
corresponding response DATA:
|
| 281 |
|
|
|
| 282 |
|
|
Packet Request Description
|
| 283 |
|
|
extended ops `!' Use the extended remote
|
| 284 |
|
|
protocol. Sticky--only
|
| 285 |
|
|
needs to be set once. The
|
| 286 |
|
|
extended remote protocol
|
| 287 |
|
|
supports the `R' packet.
|
| 288 |
|
|
reply `' Stubs that support the
|
| 289 |
|
|
extended remote protocol
|
| 290 |
|
|
return `' which,
|
| 291 |
|
|
unfortunately, is identical
|
| 292 |
|
|
to the response returned by
|
| 293 |
|
|
stubs that do not support
|
| 294 |
|
|
protocol extensions.
|
| 295 |
|
|
last signal `?' Indicate the reason the
|
| 296 |
|
|
target halted. The reply is
|
| 297 |
|
|
the same as for step and
|
| 298 |
|
|
continue.
|
| 299 |
|
|
reply see below
|
| 300 |
|
|
reserved `a' Reserved for future use
|
| 301 |
|
|
set program arguments `A'ARGLEN`,'ARGNUM`,'ARG`,...'
|
| 302 |
|
|
*(reserved)*
|
| 303 |
|
|
Initialized `argv[]' array
|
| 304 |
|
|
passed into program. ARGLEN
|
| 305 |
|
|
specifies the number of
|
| 306 |
|
|
bytes in the hex encoded
|
| 307 |
|
|
byte stream ARG. See
|
| 308 |
|
|
`gdbserver' for more details.
|
| 309 |
|
|
reply `OK'
|
| 310 |
|
|
reply `E'NN
|
| 311 |
|
|
set baud `b'BAUD Change the serial line speed
|
| 312 |
|
|
*(deprecated)* to BAUD. JTC: _When does the
|
| 313 |
|
|
transport layer state
|
| 314 |
|
|
change? When it's received,
|
| 315 |
|
|
or after the ACK is
|
| 316 |
|
|
transmitted. In either
|
| 317 |
|
|
case, there are problems if
|
| 318 |
|
|
the command or the
|
| 319 |
|
|
acknowledgment packet is
|
| 320 |
|
|
dropped._ Stan: _If people
|
| 321 |
|
|
really wanted to add
|
| 322 |
|
|
something like this, and get
|
| 323 |
|
|
it working for the first
|
| 324 |
|
|
time, they ought to modify
|
| 325 |
|
|
ser-unix.c to send some kind
|
| 326 |
|
|
of out-of-band message to a
|
| 327 |
|
|
specially-setup stub and
|
| 328 |
|
|
have the switch happen "in
|
| 329 |
|
|
between" packets, so that
|
| 330 |
|
|
from remote protocol's point
|
| 331 |
|
|
of view, nothing actually
|
| 332 |
|
|
happened._
|
| 333 |
|
|
set breakpoint `B'ADDR,MODE Set (MODE is `S') or clear
|
| 334 |
|
|
*(deprecated)* (MODE is `C') a breakpoint
|
| 335 |
|
|
at ADDR. _This has been
|
| 336 |
|
|
replaced by the `Z' and `z'
|
| 337 |
|
|
packets._
|
| 338 |
|
|
continue `c'ADDR ADDR is address to resume.
|
| 339 |
|
|
If ADDR is omitted, resume at
|
| 340 |
|
|
current address.
|
| 341 |
|
|
reply see below
|
| 342 |
|
|
continue with signal `C'SIG`;'ADDR Continue with signal SIG
|
| 343 |
|
|
(hex signal number). If
|
| 344 |
|
|
`;'ADDR is omitted, resume
|
| 345 |
|
|
at same address.
|
| 346 |
|
|
reply see below
|
| 347 |
|
|
toggle debug `d' toggle debug flag.
|
| 348 |
|
|
*(deprecated)*
|
| 349 |
|
|
detach `D' Detach GDB from the remote
|
| 350 |
|
|
system. Sent to the remote
|
| 351 |
|
|
target before GDB
|
| 352 |
|
|
disconnects.
|
| 353 |
|
|
reply _no response_ GDB does not check for any
|
| 354 |
|
|
response after sending this
|
| 355 |
|
|
packet.
|
| 356 |
|
|
reserved `e' Reserved for future use
|
| 357 |
|
|
reserved `E' Reserved for future use
|
| 358 |
|
|
reserved `f' Reserved for future use
|
| 359 |
|
|
reserved `F' Reserved for future use
|
| 360 |
|
|
read registers `g' Read general registers.
|
| 361 |
|
|
reply XX... Each byte of register data
|
| 362 |
|
|
is described by two hex
|
| 363 |
|
|
digits. The bytes with the
|
| 364 |
|
|
register are transmitted in
|
| 365 |
|
|
target byte order. The size
|
| 366 |
|
|
of each register and their
|
| 367 |
|
|
position within the `g'
|
| 368 |
|
|
PACKET are determined by the
|
| 369 |
|
|
GDB internal macros
|
| 370 |
|
|
REGISTER_RAW_SIZE and
|
| 371 |
|
|
REGISTER_NAME macros. The
|
| 372 |
|
|
specification of several
|
| 373 |
|
|
standard `g' packets is
|
| 374 |
|
|
specified below.
|
| 375 |
|
|
`E'NN for an error.
|
| 376 |
|
|
write regs `G'XX... See `g' for a description of
|
| 377 |
|
|
the XX... data.
|
| 378 |
|
|
reply `OK' for success
|
| 379 |
|
|
reply `E'NN for an error
|
| 380 |
|
|
reserved `h' Reserved for future use
|
| 381 |
|
|
set thread `H'CT... Set thread for subsequent
|
| 382 |
|
|
operations (`m', `M', `g',
|
| 383 |
|
|
`G', et.al.). C = `c' for
|
| 384 |
|
|
thread used in step and
|
| 385 |
|
|
continue; T... can be -1 for
|
| 386 |
|
|
all threads. C = `g' for
|
| 387 |
|
|
thread used in other
|
| 388 |
|
|
operations. If zero, pick a
|
| 389 |
|
|
thread, any thread.
|
| 390 |
|
|
reply `OK' for success
|
| 391 |
|
|
reply `E'NN for an error
|
| 392 |
|
|
cycle step *(draft)* `i'ADDR`,'NNN Step the remote target by a
|
| 393 |
|
|
single clock cycle. If
|
| 394 |
|
|
`,'NNN is present, cycle
|
| 395 |
|
|
step NNN cycles. If ADDR is
|
| 396 |
|
|
present, cycle step starting
|
| 397 |
|
|
at that address.
|
| 398 |
|
|
signal then cycle `I' See `i' and `S' for likely
|
| 399 |
|
|
step *(reserved)* syntax and semantics.
|
| 400 |
|
|
reserved `j' Reserved for future use
|
| 401 |
|
|
reserved `J' Reserved for future use
|
| 402 |
|
|
kill request `k' FIXME: _There is no
|
| 403 |
|
|
description of how operate
|
| 404 |
|
|
when a specific thread
|
| 405 |
|
|
context has been selected
|
| 406 |
|
|
(ie. does 'k' kill only that
|
| 407 |
|
|
thread?)_.
|
| 408 |
|
|
reserved `l' Reserved for future use
|
| 409 |
|
|
reserved `L' Reserved for future use
|
| 410 |
|
|
read memory `m'ADDR`,'LENGTH Read LENGTH bytes of memory
|
| 411 |
|
|
starting at address ADDR.
|
| 412 |
|
|
Neither GDB nor the stub
|
| 413 |
|
|
assume that sized memory
|
| 414 |
|
|
transfers are assumed using
|
| 415 |
|
|
word alligned accesses.
|
| 416 |
|
|
FIXME: _A word aligned memory
|
| 417 |
|
|
transfer mechanism is
|
| 418 |
|
|
needed._
|
| 419 |
|
|
reply XX... XX... is mem contents. Can
|
| 420 |
|
|
be fewer bytes than
|
| 421 |
|
|
requested if able to read
|
| 422 |
|
|
only part of the data.
|
| 423 |
|
|
Neither GDB nor the stub
|
| 424 |
|
|
assume that sized memory
|
| 425 |
|
|
transfers are assumed using
|
| 426 |
|
|
word alligned accesses.
|
| 427 |
|
|
FIXME: _A word aligned
|
| 428 |
|
|
memory transfer mechanism is
|
| 429 |
|
|
needed._
|
| 430 |
|
|
reply `E'NN NN is errno
|
| 431 |
|
|
write mem `M'ADDR,LENGTH`:'XX... Write LENGTH bytes of memory
|
| 432 |
|
|
starting at address ADDR.
|
| 433 |
|
|
XX... is the data.
|
| 434 |
|
|
reply `OK' for success
|
| 435 |
|
|
reply `E'NN for an error (this includes
|
| 436 |
|
|
the case where only part of
|
| 437 |
|
|
the data was written).
|
| 438 |
|
|
reserved `n' Reserved for future use
|
| 439 |
|
|
reserved `N' Reserved for future use
|
| 440 |
|
|
reserved `o' Reserved for future use
|
| 441 |
|
|
reserved `O' Reserved for future use
|
| 442 |
|
|
read reg *(reserved)* `p'N... See write register.
|
| 443 |
|
|
return R.... The hex encoded value of the
|
| 444 |
|
|
register in target byte
|
| 445 |
|
|
order.
|
| 446 |
|
|
write reg `P'N...`='R... Write register N... with
|
| 447 |
|
|
value R..., which contains
|
| 448 |
|
|
two hex digits for each byte
|
| 449 |
|
|
in the register (target byte
|
| 450 |
|
|
order).
|
| 451 |
|
|
reply `OK' for success
|
| 452 |
|
|
reply `E'NN for an error
|
| 453 |
|
|
general query `q'QUERY Request info about QUERY.
|
| 454 |
|
|
In general GDB queries have
|
| 455 |
|
|
a leading upper case letter.
|
| 456 |
|
|
Custom vendor queries
|
| 457 |
|
|
should use a company prefix
|
| 458 |
|
|
(in lower case) ex:
|
| 459 |
|
|
`qfsf.var'. QUERY may
|
| 460 |
|
|
optionally be followed by a
|
| 461 |
|
|
`,' or `;' separated list.
|
| 462 |
|
|
Stubs must ensure that they
|
| 463 |
|
|
match the full QUERY name.
|
| 464 |
|
|
reply `XX...' Hex encoded data from query.
|
| 465 |
|
|
The reply can not be empty.
|
| 466 |
|
|
reply `E'NN error reply
|
| 467 |
|
|
reply `' Indicating an unrecognized
|
| 468 |
|
|
QUERY.
|
| 469 |
|
|
general set `Q'VAR`='VAL Set value of VAR to VAL.
|
| 470 |
|
|
See `q' for a discussing of
|
| 471 |
|
|
naming conventions.
|
| 472 |
|
|
reset *(deprecated)* `r' Reset the entire system.
|
| 473 |
|
|
remote restart `R'XX Restart the remote server.
|
| 474 |
|
|
XX while needed has no clear
|
| 475 |
|
|
definition. FIXME: _An
|
| 476 |
|
|
example interaction
|
| 477 |
|
|
explaining how this packet
|
| 478 |
|
|
is used in extended-remote
|
| 479 |
|
|
mode is needed_.
|
| 480 |
|
|
step `s'ADDR ADDR is address to resume.
|
| 481 |
|
|
If ADDR is omitted, resume at
|
| 482 |
|
|
same address.
|
| 483 |
|
|
reply see below
|
| 484 |
|
|
step with signal `S'SIG`;'ADDR Like `C' but step not
|
| 485 |
|
|
continue.
|
| 486 |
|
|
reply see below
|
| 487 |
|
|
search `t'ADDR`:'PP`,'MM Search backwards starting at
|
| 488 |
|
|
address ADDR for a match
|
| 489 |
|
|
with pattern PP and mask MM.
|
| 490 |
|
|
PP and MM are 4 bytes.
|
| 491 |
|
|
ADDR must be at least 3
|
| 492 |
|
|
digits.
|
| 493 |
|
|
thread alive `T'XX Find out if the thread XX is
|
| 494 |
|
|
alive.
|
| 495 |
|
|
reply `OK' thread is still alive
|
| 496 |
|
|
reply `E'NN thread is dead
|
| 497 |
|
|
reserved `u' Reserved for future use
|
| 498 |
|
|
reserved `U' Reserved for future use
|
| 499 |
|
|
reserved `v' Reserved for future use
|
| 500 |
|
|
reserved `V' Reserved for future use
|
| 501 |
|
|
reserved `w' Reserved for future use
|
| 502 |
|
|
reserved `W' Reserved for future use
|
| 503 |
|
|
reserved `x' Reserved for future use
|
| 504 |
|
|
write mem (binary) `X'ADDR`,'LENGTH:XX... ADDR is address, LENGTH is
|
| 505 |
|
|
number of bytes, XX... is
|
| 506 |
|
|
binary data. The characters
|
| 507 |
|
|
`$', `#', and `0x7d' are
|
| 508 |
|
|
escaped using `0x7d'.
|
| 509 |
|
|
reply `OK' for success
|
| 510 |
|
|
reply `E'NN for an error
|
| 511 |
|
|
reserved `y' Reserved for future use
|
| 512 |
|
|
reserved `Y' Reserved for future use
|
| 513 |
|
|
remove break or `z'T`,'ADDR`,'LENGTH See `Z'.
|
| 514 |
|
|
watchpoint *(draft)*
|
| 515 |
|
|
insert break or `Z'T`,'ADDR`,'LENGTH T is type: `0' - software
|
| 516 |
|
|
watchpoint *(draft)* breakpoint, `1' - hardware
|
| 517 |
|
|
breakpoint, `2' - write
|
| 518 |
|
|
watchpoint, `3' - read
|
| 519 |
|
|
watchpoint, `4' - access
|
| 520 |
|
|
watchpoint; ADDR is address;
|
| 521 |
|
|
LENGTH is in bytes. For a
|
| 522 |
|
|
software breakpoint, LENGTH
|
| 523 |
|
|
specifies the size of the
|
| 524 |
|
|
instruction to be patched.
|
| 525 |
|
|
For hardware breakpoints and
|
| 526 |
|
|
watchpoints LENGTH specifies
|
| 527 |
|
|
the memory region to be
|
| 528 |
|
|
monitored. To avoid
|
| 529 |
|
|
potential problems with
|
| 530 |
|
|
duplicate packets, the
|
| 531 |
|
|
operations should be
|
| 532 |
|
|
implemented in an idempotent
|
| 533 |
|
|
way.
|
| 534 |
|
|
reply `E'NN for an error
|
| 535 |
|
|
reply `OK' for success
|
| 536 |
|
|
`' If not supported.
|
| 537 |
|
|
reserved Reserved for future use
|
| 538 |
|
|
|
| 539 |
|
|
The `C', `c', `S', `s' and `?' packets can receive any of the below
|
| 540 |
|
|
as a reply. In the case of the `C', `c', `S' and `s' packets, that
|
| 541 |
|
|
reply is only returned when the target halts. In the below the exact
|
| 542 |
|
|
meaning of `signal number' is poorly defined. In general one of the
|
| 543 |
|
|
UNIX signal numbering conventions is used.
|
| 544 |
|
|
|
| 545 |
|
|
`S'AA AA is the signal number
|
| 546 |
|
|
`T'AAN...`:'R...`;'N...`:'R...`;'N...`:'R...`;'AA = two hex digit signal number; N... =
|
| 547 |
|
|
register number (hex), R... = target byte
|
| 548 |
|
|
ordered register contents, size defined by
|
| 549 |
|
|
`REGISTER_RAW_SIZE'; N... = `thread', R...
|
| 550 |
|
|
= thread process ID, this is a hex
|
| 551 |
|
|
integer; N... = other string not starting
|
| 552 |
|
|
with valid hex digit. GDB should ignore
|
| 553 |
|
|
this N..., R... pair and go on to the
|
| 554 |
|
|
next. This way we can extend the protocol.
|
| 555 |
|
|
`W'AA The process exited, and AA is the exit
|
| 556 |
|
|
status. This is only applicable for
|
| 557 |
|
|
certains sorts of targets.
|
| 558 |
|
|
`X'AA The process terminated with signal AA.
|
| 559 |
|
|
`N'AA`;'T...`;'D...`;'B... AA = signal number; T... = address of
|
| 560 |
|
|
*(obsolete)* symbol "_start"; D... = base of data
|
| 561 |
|
|
section; B... = base of bss section.
|
| 562 |
|
|
_Note: only used by Cisco Systems targets.
|
| 563 |
|
|
The difference between this reply and the
|
| 564 |
|
|
"qOffsets" query is that the 'N' packet
|
| 565 |
|
|
may arrive spontaneously whereas the
|
| 566 |
|
|
'qOffsets' is a query initiated by the host
|
| 567 |
|
|
debugger._
|
| 568 |
|
|
`O'XX... XX... is hex encoding of ASCII data. This
|
| 569 |
|
|
can happen at any time while the program
|
| 570 |
|
|
is running and the debugger should
|
| 571 |
|
|
continue to wait for 'W', 'T', etc.
|
| 572 |
|
|
|
| 573 |
|
|
The following set and query packets have already been defined.
|
| 574 |
|
|
|
| 575 |
|
|
current thread `q'`C' Return the current thread id.
|
| 576 |
|
|
reply `QC'PID Where PID is a HEX encoded 16 bit process
|
| 577 |
|
|
id.
|
| 578 |
|
|
reply * Any other reply implies the old pid.
|
| 579 |
|
|
all thread ids `q'`fThreadInfo'
|
| 580 |
|
|
`q'`sThreadInfo'Obtain a list of active thread ids from
|
| 581 |
|
|
the target (OS). Since there may be too
|
| 582 |
|
|
many active threads to fit into one reply
|
| 583 |
|
|
packet, this query works iteratively: it
|
| 584 |
|
|
may require more than one query/reply
|
| 585 |
|
|
sequence to obtain the entire list of
|
| 586 |
|
|
threads. The first query of the sequence
|
| 587 |
|
|
will be the `qf'`ThreadInfo' query;
|
| 588 |
|
|
subsequent queries in the sequence will be
|
| 589 |
|
|
the `qs'`ThreadInfo' query.
|
| 590 |
|
|
NOTE: replaces the `qL' query (see below).
|
| 591 |
|
|
reply `m' A single thread id
|
| 592 |
|
|
reply a comma-separated list of thread ids
|
| 593 |
|
|
`m',...
|
| 594 |
|
|
reply `l' (lower case 'el') denotes end of list.
|
| 595 |
|
|
In response to each query, the target will
|
| 596 |
|
|
reply with a list of one or more thread
|
| 597 |
|
|
ids, in big-endian hex, separated by
|
| 598 |
|
|
commas. GDB will respond to each reply
|
| 599 |
|
|
with a request for more thread ids (using
|
| 600 |
|
|
the `qs' form of the query), until the
|
| 601 |
|
|
target responds with `l' (lower-case el,
|
| 602 |
|
|
for `'last'').
|
| 603 |
|
|
extra thread `q'`ThreadExtraInfo'`,'ID
|
| 604 |
|
|
info
|
| 605 |
|
|
Where is a thread-id in big-endian
|
| 606 |
|
|
hex. Obtain a printable string
|
| 607 |
|
|
description of a thread's attributes from
|
| 608 |
|
|
the target OS. This string may contain
|
| 609 |
|
|
anything that the target OS thinks is
|
| 610 |
|
|
interesting for GDB to tell the user about
|
| 611 |
|
|
the thread. The string is displayed in
|
| 612 |
|
|
GDB's `info threads' display. Some
|
| 613 |
|
|
examples of possible thread extra info
|
| 614 |
|
|
strings are "Runnable", or "Blocked on
|
| 615 |
|
|
Mutex".
|
| 616 |
|
|
reply XX... Where XX... is a hex encoding of ASCII
|
| 617 |
|
|
data, comprising the printable string
|
| 618 |
|
|
containing the extra information about the
|
| 619 |
|
|
thread's attributes.
|
| 620 |
|
|
query LIST or `q'`L'STARTFLAGTHREADCOUNTNEXTTHREAD
|
| 621 |
|
|
THREADLIST
|
| 622 |
|
|
*(deprecated)*
|
| 623 |
|
|
Obtain thread information from RTOS.
|
| 624 |
|
|
Where: STARTFLAG (one hex digit) is one to
|
| 625 |
|
|
indicate the first query and zero to
|
| 626 |
|
|
indicate a subsequent query; THREADCOUNT
|
| 627 |
|
|
(two hex digits) is the maximum number of
|
| 628 |
|
|
threads the response packet can contain;
|
| 629 |
|
|
and NEXTTHREAD (eight hex digits), for
|
| 630 |
|
|
subsequent queries (STARTFLAG is zero), is
|
| 631 |
|
|
returned in the response as ARGTHREAD.
|
| 632 |
|
|
NOTE: this query is replaced by the
|
| 633 |
|
|
`q'`fThreadInfo' query (see above).
|
| 634 |
|
|
reply
|
| 635 |
|
|
`q'`M'COUNTDONEARGTHREADTHREAD...
|
| 636 |
|
|
Where: COUNT (two hex digits) is the
|
| 637 |
|
|
number of threads being returned; DONE
|
| 638 |
|
|
(one hex digit) is zero to indicate more
|
| 639 |
|
|
threads and one indicates no further
|
| 640 |
|
|
threads; ARGTHREADID (eight hex digits) is
|
| 641 |
|
|
NEXTTHREAD from the request packet;
|
| 642 |
|
|
THREAD... is a sequence of thread IDs from
|
| 643 |
|
|
the target. THREADID (eight hex digits).
|
| 644 |
|
|
See `remote.c:parse_threadlist_response()'.
|
| 645 |
|
|
compute CRC `q'`CRC:'ADDR`,'LENGTH
|
| 646 |
|
|
of memory
|
| 647 |
|
|
block
|
| 648 |
|
|
reply `E'NN An error (such as memory fault)
|
| 649 |
|
|
reply `C'CRC32 A 32 bit cyclic redundancy check of the
|
| 650 |
|
|
specified memory region.
|
| 651 |
|
|
query sect `q'`Offsets' Get section offsets that the target used
|
| 652 |
|
|
offs when re-locating the downloaded image.
|
| 653 |
|
|
_Note: while a `Bss' offset is included in
|
| 654 |
|
|
the response, GDB ignores this and instead
|
| 655 |
|
|
applies the `Data' offset to the `Bss'
|
| 656 |
|
|
section._
|
| 657 |
|
|
reply
|
| 658 |
|
|
`Text='XXX`;Data='YYY`;Bss='ZZZ
|
| 659 |
|
|
thread info `q'`P'MODETHREADID
|
| 660 |
|
|
request
|
| 661 |
|
|
Returns information on THREADID. Where:
|
| 662 |
|
|
MODE is a hex encoded 32 bit mode;
|
| 663 |
|
|
THREADID is a hex encoded 64 bit thread ID.
|
| 664 |
|
|
reply * See
|
| 665 |
|
|
`remote.c:remote_unpack_thread_info_response()'.
|
| 666 |
|
|
remote command `q'`Rcmd,'COMMAND
|
| 667 |
|
|
COMMAND (hex encoded) is passed to the
|
| 668 |
|
|
local interpreter for execution. Invalid
|
| 669 |
|
|
commands should be reported using the
|
| 670 |
|
|
output string. Before the final result
|
| 671 |
|
|
packet, the target may also respond with a
|
| 672 |
|
|
number of intermediate `O'OUTPUT console
|
| 673 |
|
|
output packets. _Implementors should note
|
| 674 |
|
|
that providing access to a stubs's
|
| 675 |
|
|
interpreter may have security
|
| 676 |
|
|
implications_.
|
| 677 |
|
|
reply `OK' A command response with no output.
|
| 678 |
|
|
reply OUTPUT A command response with the hex encoded
|
| 679 |
|
|
output string OUTPUT.
|
| 680 |
|
|
reply `E'NN Indicate a badly formed request.
|
| 681 |
|
|
reply `' When `q'`Rcmd' is not recognized.
|
| 682 |
|
|
|
| 683 |
|
|
The following `g'/`G' packets have previously been defined. In the
|
| 684 |
|
|
below, some thirty-two bit registers are transferred as sixty-four
|
| 685 |
|
|
bits. Those registers should be zero/sign extended (which?) to fill the
|
| 686 |
|
|
space allocated. Register bytes are transfered in target byte order.
|
| 687 |
|
|
The two nibbles within a register byte are transfered most-significant -
|
| 688 |
|
|
least-significant.
|
| 689 |
|
|
|
| 690 |
|
|
MIPS32 All registers are transfered as
|
| 691 |
|
|
thirty-two bit quantities in the
|
| 692 |
|
|
order: 32 general-purpose; sr; lo;
|
| 693 |
|
|
hi; bad; cause; pc; 32
|
| 694 |
|
|
floating-point registers; fsr; fir;
|
| 695 |
|
|
fp.
|
| 696 |
|
|
MIPS64 All registers are transfered as
|
| 697 |
|
|
sixty-four bit quantities (including
|
| 698 |
|
|
thirty-two bit registers such as
|
| 699 |
|
|
`sr'). The ordering is the same as
|
| 700 |
|
|
`MIPS32'.
|
| 701 |
|
|
|
| 702 |
|
|
Example sequence of a target being re-started. Notice how the
|
| 703 |
|
|
restart does not get any direct output:
|
| 704 |
|
|
|
| 705 |
|
|
<- `R00'
|
| 706 |
|
|
-> `+'
|
| 707 |
|
|
_target restarts_
|
| 708 |
|
|
<- `?'
|
| 709 |
|
|
-> `+'
|
| 710 |
|
|
-> `T001:1234123412341234'
|
| 711 |
|
|
<- `+'
|
| 712 |
|
|
|
| 713 |
|
|
Example sequence of a target being stepped by a single instruction:
|
| 714 |
|
|
|
| 715 |
|
|
<- `G1445...'
|
| 716 |
|
|
-> `+'
|
| 717 |
|
|
<- `s'
|
| 718 |
|
|
-> `+'
|
| 719 |
|
|
_time passes_
|
| 720 |
|
|
-> `T001:1234123412341234'
|
| 721 |
|
|
<- `+'
|
| 722 |
|
|
<- `g'
|
| 723 |
|
|
-> `+'
|
| 724 |
|
|
-> `1455...'
|
| 725 |
|
|
<- `+'
|
| 726 |
|
|
|
| 727 |
|
|
|
| 728 |
|
|
File: gdb.info, Node: Server, Next: NetWare, Prev: Protocol, Up: Remote Serial
|
| 729 |
|
|
|
| 730 |
|
|
Using the `gdbserver' program
|
| 731 |
|
|
.............................
|
| 732 |
|
|
|
| 733 |
|
|
`gdbserver' is a control program for Unix-like systems, which allows
|
| 734 |
|
|
you to connect your program with a remote GDB via `target remote'--but
|
| 735 |
|
|
without linking in the usual debugging stub.
|
| 736 |
|
|
|
| 737 |
|
|
`gdbserver' is not a complete replacement for the debugging stubs,
|
| 738 |
|
|
because it requires essentially the same operating-system facilities
|
| 739 |
|
|
that GDB itself does. In fact, a system that can run `gdbserver' to
|
| 740 |
|
|
connect to a remote GDB could also run GDB locally! `gdbserver' is
|
| 741 |
|
|
sometimes useful nevertheless, because it is a much smaller program
|
| 742 |
|
|
than GDB itself. It is also easier to port than all of GDB, so you may
|
| 743 |
|
|
be able to get started more quickly on a new system by using
|
| 744 |
|
|
`gdbserver'. Finally, if you develop code for real-time systems, you
|
| 745 |
|
|
may find that the tradeoffs involved in real-time operation make it
|
| 746 |
|
|
more convenient to do as much development work as possible on another
|
| 747 |
|
|
system, for example by cross-compiling. You can use `gdbserver' to
|
| 748 |
|
|
make a similar choice for debugging.
|
| 749 |
|
|
|
| 750 |
|
|
GDB and `gdbserver' communicate via either a serial line or a TCP
|
| 751 |
|
|
connection, using the standard GDB remote serial protocol.
|
| 752 |
|
|
|
| 753 |
|
|
_On the target machine,_
|
| 754 |
|
|
you need to have a copy of the program you want to debug.
|
| 755 |
|
|
`gdbserver' does not need your program's symbol table, so you can
|
| 756 |
|
|
strip the program if necessary to save space. GDB on the host
|
| 757 |
|
|
system does all the symbol handling.
|
| 758 |
|
|
|
| 759 |
|
|
To use the server, you must tell it how to communicate with GDB;
|
| 760 |
|
|
the name of your program; and the arguments for your program. The
|
| 761 |
|
|
syntax is:
|
| 762 |
|
|
|
| 763 |
|
|
target> gdbserver COMM PROGRAM [ ARGS ... ]
|
| 764 |
|
|
|
| 765 |
|
|
COMM is either a device name (to use a serial line) or a TCP
|
| 766 |
|
|
hostname and portnumber. For example, to debug Emacs with the
|
| 767 |
|
|
argument `foo.txt' and communicate with GDB over the serial port
|
| 768 |
|
|
`/dev/com1':
|
| 769 |
|
|
|
| 770 |
|
|
target> gdbserver /dev/com1 emacs foo.txt
|
| 771 |
|
|
|
| 772 |
|
|
`gdbserver' waits passively for the host GDB to communicate with
|
| 773 |
|
|
it.
|
| 774 |
|
|
|
| 775 |
|
|
To use a TCP connection instead of a serial line:
|
| 776 |
|
|
|
| 777 |
|
|
target> gdbserver host:2345 emacs foo.txt
|
| 778 |
|
|
|
| 779 |
|
|
The only difference from the previous example is the first
|
| 780 |
|
|
argument, specifying that you are communicating with the host GDB
|
| 781 |
|
|
via TCP. The `host:2345' argument means that `gdbserver' is to
|
| 782 |
|
|
expect a TCP connection from machine `host' to local TCP port 2345.
|
| 783 |
|
|
(Currently, the `host' part is ignored.) You can choose any number
|
| 784 |
|
|
you want for the port number as long as it does not conflict with
|
| 785 |
|
|
any TCP ports already in use on the target system (for example,
|
| 786 |
|
|
`23' is reserved for `telnet').(1) You must use the same port
|
| 787 |
|
|
number with the host GDB `target remote' command.
|
| 788 |
|
|
|
| 789 |
|
|
_On the GDB host machine,_
|
| 790 |
|
|
you need an unstripped copy of your program, since GDB needs
|
| 791 |
|
|
symbols and debugging information. Start up GDB as usual, using
|
| 792 |
|
|
the name of the local copy of your program as the first argument.
|
| 793 |
|
|
(You may also need the `--baud' option if the serial line is
|
| 794 |
|
|
running at anything other than 9600bps.) After that, use `target
|
| 795 |
|
|
remote' to establish communications with `gdbserver'. Its argument
|
| 796 |
|
|
is either a device name (usually a serial device, like
|
| 797 |
|
|
`/dev/ttyb'), or a TCP port descriptor in the form `HOST:PORT'.
|
| 798 |
|
|
For example:
|
| 799 |
|
|
|
| 800 |
|
|
(gdb) target remote /dev/ttyb
|
| 801 |
|
|
|
| 802 |
|
|
communicates with the server via serial line `/dev/ttyb', and
|
| 803 |
|
|
|
| 804 |
|
|
(gdb) target remote the-target:2345
|
| 805 |
|
|
|
| 806 |
|
|
communicates via a TCP connection to port 2345 on host
|
| 807 |
|
|
`the-target'. For TCP connections, you must start up `gdbserver'
|
| 808 |
|
|
prior to using the `target remote' command. Otherwise you may get
|
| 809 |
|
|
an error whose text depends on the host system, but which usually
|
| 810 |
|
|
looks something like `Connection refused'.
|
| 811 |
|
|
|
| 812 |
|
|
---------- Footnotes ----------
|
| 813 |
|
|
|
| 814 |
|
|
(1) If you choose a port number that conflicts with another service,
|
| 815 |
|
|
`gdbserver' prints an error message and exits.
|
| 816 |
|
|
|
| 817 |
|
|
|
| 818 |
|
|
File: gdb.info, Node: NetWare, Prev: Server, Up: Remote Serial
|
| 819 |
|
|
|
| 820 |
|
|
Using the `gdbserve.nlm' program
|
| 821 |
|
|
................................
|
| 822 |
|
|
|
| 823 |
|
|
`gdbserve.nlm' is a control program for NetWare systems, which
|
| 824 |
|
|
allows you to connect your program with a remote GDB via `target
|
| 825 |
|
|
remote'.
|
| 826 |
|
|
|
| 827 |
|
|
GDB and `gdbserve.nlm' communicate via a serial line, using the
|
| 828 |
|
|
standard GDB remote serial protocol.
|
| 829 |
|
|
|
| 830 |
|
|
_On the target machine,_
|
| 831 |
|
|
you need to have a copy of the program you want to debug.
|
| 832 |
|
|
`gdbserve.nlm' does not need your program's symbol table, so you
|
| 833 |
|
|
can strip the program if necessary to save space. GDB on the host
|
| 834 |
|
|
system does all the symbol handling.
|
| 835 |
|
|
|
| 836 |
|
|
To use the server, you must tell it how to communicate with GDB;
|
| 837 |
|
|
the name of your program; and the arguments for your program. The
|
| 838 |
|
|
syntax is:
|
| 839 |
|
|
|
| 840 |
|
|
load gdbserve [ BOARD=BOARD ] [ PORT=PORT ]
|
| 841 |
|
|
[ BAUD=BAUD ] PROGRAM [ ARGS ... ]
|
| 842 |
|
|
|
| 843 |
|
|
BOARD and PORT specify the serial line; BAUD specifies the baud
|
| 844 |
|
|
rate used by the connection. PORT and NODE default to 0, BAUD
|
| 845 |
|
|
defaults to 9600bps.
|
| 846 |
|
|
|
| 847 |
|
|
For example, to debug Emacs with the argument `foo.txt'and
|
| 848 |
|
|
communicate with GDB over serial port number 2 or board 1 using a
|
| 849 |
|
|
19200bps connection:
|
| 850 |
|
|
|
| 851 |
|
|
load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt
|
| 852 |
|
|
|
| 853 |
|
|
_On the GDB host machine,_
|
| 854 |
|
|
you need an unstripped copy of your program, since GDB needs
|
| 855 |
|
|
symbols and debugging information. Start up GDB as usual, using
|
| 856 |
|
|
the name of the local copy of your program as the first argument.
|
| 857 |
|
|
(You may also need the `--baud' option if the serial line is
|
| 858 |
|
|
running at anything other than 9600bps. After that, use `target
|
| 859 |
|
|
remote' to establish communications with `gdbserve.nlm'. Its
|
| 860 |
|
|
argument is a device name (usually a serial device, like
|
| 861 |
|
|
`/dev/ttyb'). For example:
|
| 862 |
|
|
|
| 863 |
|
|
(gdb) target remote /dev/ttyb
|
| 864 |
|
|
|
| 865 |
|
|
communications with the server via serial line `/dev/ttyb'.
|
| 866 |
|
|
|
| 867 |
|
|
|
| 868 |
|
|
File: gdb.info, Node: KOD, Prev: Remote, Up: Targets
|
| 869 |
|
|
|
| 870 |
|
|
Kernel Object Display
|
| 871 |
|
|
=====================
|
| 872 |
|
|
|
| 873 |
|
|
Some targets support kernel object display. Using this facility,
|
| 874 |
|
|
GDB communicates specially with the underlying operating system and can
|
| 875 |
|
|
display information about operating system-level objects such as
|
| 876 |
|
|
mutexes and other synchronization objects. Exactly which objects can be
|
| 877 |
|
|
displayed is determined on a per-OS basis.
|
| 878 |
|
|
|
| 879 |
|
|
Use the `set os' command to set the operating system. This tells
|
| 880 |
|
|
GDB which kernel object display module to initialize:
|
| 881 |
|
|
|
| 882 |
|
|
(gdb) set os cisco
|
| 883 |
|
|
|
| 884 |
|
|
If `set os' succeeds, GDB will display some information about the
|
| 885 |
|
|
operating system, and will create a new `info' command which can be
|
| 886 |
|
|
used to query the target. The `info' command is named after the
|
| 887 |
|
|
operating system:
|
| 888 |
|
|
|
| 889 |
|
|
(gdb) info cisco
|
| 890 |
|
|
List of Cisco Kernel Objects
|
| 891 |
|
|
Object Description
|
| 892 |
|
|
any Any and all objects
|
| 893 |
|
|
|
| 894 |
|
|
Further subcommands can be used to query about particular objects
|
| 895 |
|
|
known by the kernel.
|
| 896 |
|
|
|
| 897 |
|
|
There is currently no way to determine whether a given operating
|
| 898 |
|
|
system is supported other than to try it.
|
| 899 |
|
|
|
