1 |
578 |
markom |
This is ./gdb.info, produced by makeinfo version 4.0 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 Ninth Edition, April 2001, of `Debugging with GDB: the
|
11 |
|
|
GNU Source-Level Debugger' for GDB Version 20010707.
|
12 |
|
|
|
13 |
|
|
Copyright (C)
|
14 |
|
|
1988,1989,1990,1991,1992,1993,1994,1995,1996,1998,1999,2000,2001
|
15 |
|
|
Free Software Foundation, Inc.
|
16 |
|
|
|
17 |
|
|
Permission is granted to copy, distribute and/or modify this document
|
18 |
|
|
under the terms of the GNU Free Documentation License, Version 1.1 or
|
19 |
|
|
any later version published by the Free Software Foundation; with the
|
20 |
|
|
Invariant Sections being "A Sample GDB Session" and "Free Software",
|
21 |
|
|
with the Front-Cover texts being "A GNU Manual," and with the
|
22 |
|
|
Back-Cover Texts as in (a) below.
|
23 |
|
|
|
24 |
|
|
(a) The FSF's Back-Cover Text is: "You have freedom to copy and
|
25 |
|
|
modify this GNU Manual, like GNU software. Copies published by the Free
|
26 |
|
|
Software Foundation raise funds for GNU development."
|
27 |
|
|
|
28 |
|
|
|
29 |
|
|
File: gdb.info, Node: Protocol, Next: Server, Prev: Debug Session, Up: Remote Serial
|
30 |
|
|
|
31 |
|
|
Communication protocol
|
32 |
|
|
......................
|
33 |
|
|
|
34 |
|
|
The stub files provided with GDB implement the target side of the
|
35 |
|
|
communication protocol, and the GDB side is implemented in the GDB
|
36 |
|
|
source file `remote.c'. Normally, you can simply allow these
|
37 |
|
|
subroutines to communicate, and ignore the details. (If you're
|
38 |
|
|
implementing your own stub file, you can still ignore the details: start
|
39 |
|
|
with one of the existing stub files. `sparc-stub.c' is the best
|
40 |
|
|
organized, and therefore the easiest to read.)
|
41 |
|
|
|
42 |
|
|
However, there may be occasions when you need to know something about
|
43 |
|
|
the protocol--for example, if there is only one serial port to your
|
44 |
|
|
target machine, you might want your program to do something special if
|
45 |
|
|
it recognizes a packet meant for GDB.
|
46 |
|
|
|
47 |
|
|
In the examples below, `<-' and `->' are used to indicate
|
48 |
|
|
transmitted and received data respectfully.
|
49 |
|
|
|
50 |
|
|
All GDB commands and responses (other than acknowledgments) are sent
|
51 |
|
|
as a PACKET. A PACKET is introduced with the character `$', the actual
|
52 |
|
|
PACKET-DATA, and the terminating character `#' followed by a two-digit
|
53 |
|
|
CHECKSUM:
|
54 |
|
|
|
55 |
|
|
`$'PACKET-DATA`#'CHECKSUM
|
56 |
|
|
|
57 |
|
|
The two-digit CHECKSUM is computed as the modulo 256 sum of all
|
58 |
|
|
characters between the leading `$' and the trailing `#' (an eight bit
|
59 |
|
|
unsigned checksum).
|
60 |
|
|
|
61 |
|
|
Implementors should note that prior to GDB 5.0 the protocol
|
62 |
|
|
specification also included an optional two-digit SEQUENCE-ID:
|
63 |
|
|
|
64 |
|
|
`$'SEQUENCE-ID`:'PACKET-DATA`#'CHECKSUM
|
65 |
|
|
|
66 |
|
|
That SEQUENCE-ID was appended to the acknowledgment. GDB has never
|
67 |
|
|
output SEQUENCE-IDs. Stubs that handle packets added since GDB 5.0
|
68 |
|
|
must not accept SEQUENCE-ID.
|
69 |
|
|
|
70 |
|
|
When either the host or the target machine receives a packet, the
|
71 |
|
|
first response expected is an acknowledgment: either `+' (to indicate
|
72 |
|
|
the package was received correctly) or `-' (to request retransmission):
|
73 |
|
|
|
74 |
|
|
<- `$'PACKET-DATA`#'CHECKSUM
|
75 |
|
|
-> `+'
|
76 |
|
|
|
77 |
|
|
The host (GDB) sends COMMANDs, and the target (the debugging stub
|
78 |
|
|
incorporated in your program) sends a RESPONSE. In the case of step
|
79 |
|
|
and continue COMMANDs, the response is only sent when the operation has
|
80 |
|
|
completed (the target has again stopped).
|
81 |
|
|
|
82 |
|
|
PACKET-DATA consists of a sequence of characters with the exception
|
83 |
|
|
of `#' and `$' (see `X' packet for additional exceptions).
|
84 |
|
|
|
85 |
|
|
Fields within the packet should be separated using `,' `;' or `:'.
|
86 |
|
|
Except where otherwise noted all numbers are represented in HEX with
|
87 |
|
|
leading zeros suppressed.
|
88 |
|
|
|
89 |
|
|
Implementors should note that prior to GDB 5.0, the character `:'
|
90 |
|
|
could not appear as the third character in a packet (as it would
|
91 |
|
|
potentially conflict with the SEQUENCE-ID).
|
92 |
|
|
|
93 |
|
|
Response DATA can be run-length encoded to save space. A `*' means
|
94 |
|
|
that the next character is an ASCII encoding giving a repeat count
|
95 |
|
|
which stands for that many repetitions of the character preceding the
|
96 |
|
|
`*'. The encoding is `n+29', yielding a printable character where `n
|
97 |
|
|
>=3' (which is where rle starts to win). The printable characters `$',
|
98 |
|
|
`#', `+' and `-' or with a numeric value greater than 126 should not be
|
99 |
|
|
used.
|
100 |
|
|
|
101 |
|
|
Some remote systems have used a different run-length encoding
|
102 |
|
|
mechanism loosely refered to as the cisco encoding. Following the `*'
|
103 |
|
|
character are two hex digits that indicate the size of the packet.
|
104 |
|
|
|
105 |
|
|
So:
|
106 |
|
|
"`0* '"
|
107 |
|
|
|
108 |
|
|
means the same as "0000".
|
109 |
|
|
|
110 |
|
|
The error response returned for some packets includes a two character
|
111 |
|
|
error number. That number is not well defined.
|
112 |
|
|
|
113 |
|
|
For any COMMAND not supported by the stub, an empty response
|
114 |
|
|
(`$#00') should be returned. That way it is possible to extend the
|
115 |
|
|
protocol. A newer GDB can tell if a packet is supported based on that
|
116 |
|
|
response.
|
117 |
|
|
|
118 |
|
|
A stub is required to support the `g', `G', `m', `M', `c', and `s'
|
119 |
|
|
COMMANDs. All other COMMANDs are optional.
|
120 |
|
|
|
121 |
|
|
Below is a complete list of all currently defined COMMANDs and their
|
122 |
|
|
corresponding response DATA:
|
123 |
|
|
|
124 |
|
|
Packet Request Description
|
125 |
|
|
extended mode `!' Enable extended mode. In
|
126 |
|
|
extended mode, the remote
|
127 |
|
|
server is made persistent.
|
128 |
|
|
The `R' packet is used to
|
129 |
|
|
restart the program being
|
130 |
|
|
debugged.
|
131 |
|
|
reply `OK' The remote target both
|
132 |
|
|
supports and has enabled
|
133 |
|
|
extended mode.
|
134 |
|
|
last signal `?' Indicate the reason the
|
135 |
|
|
target halted. The reply is
|
136 |
|
|
the same as for step and
|
137 |
|
|
continue.
|
138 |
|
|
reply see below
|
139 |
|
|
reserved `a' Reserved for future use
|
140 |
|
|
set program arguments `A'ARGLEN`,'ARGNUM`,'ARG`,...'
|
141 |
|
|
*(reserved)*
|
142 |
|
|
Initialized `argv[]' array
|
143 |
|
|
passed into program. ARGLEN
|
144 |
|
|
specifies the number of
|
145 |
|
|
bytes in the hex encoded
|
146 |
|
|
byte stream ARG. See
|
147 |
|
|
`gdbserver' for more details.
|
148 |
|
|
reply `OK'
|
149 |
|
|
reply `E'NN
|
150 |
|
|
set baud `b'BAUD Change the serial line speed
|
151 |
|
|
*(deprecated)* to BAUD. JTC: _When does the
|
152 |
|
|
transport layer state
|
153 |
|
|
change? When it's received,
|
154 |
|
|
or after the ACK is
|
155 |
|
|
transmitted. In either
|
156 |
|
|
case, there are problems if
|
157 |
|
|
the command or the
|
158 |
|
|
acknowledgment packet is
|
159 |
|
|
dropped._ Stan: _If people
|
160 |
|
|
really wanted to add
|
161 |
|
|
something like this, and get
|
162 |
|
|
it working for the first
|
163 |
|
|
time, they ought to modify
|
164 |
|
|
ser-unix.c to send some kind
|
165 |
|
|
of out-of-band message to a
|
166 |
|
|
specially-setup stub and
|
167 |
|
|
have the switch happen "in
|
168 |
|
|
between" packets, so that
|
169 |
|
|
from remote protocol's point
|
170 |
|
|
of view, nothing actually
|
171 |
|
|
happened._
|
172 |
|
|
set breakpoint `B'ADDR,MODE Set (MODE is `S') or clear
|
173 |
|
|
*(deprecated)* (MODE is `C') a breakpoint
|
174 |
|
|
at ADDR. _This has been
|
175 |
|
|
replaced by the `Z' and `z'
|
176 |
|
|
packets._
|
177 |
|
|
continue `c'ADDR ADDR is address to resume.
|
178 |
|
|
If ADDR is omitted, resume at
|
179 |
|
|
current address.
|
180 |
|
|
reply see below
|
181 |
|
|
continue with signal `C'SIG`;'ADDR Continue with signal SIG
|
182 |
|
|
(hex signal number). If
|
183 |
|
|
`;'ADDR is omitted, resume
|
184 |
|
|
at same address.
|
185 |
|
|
reply see below
|
186 |
|
|
toggle debug `d' toggle debug flag.
|
187 |
|
|
*(deprecated)*
|
188 |
|
|
detach `D' Detach GDB from the remote
|
189 |
|
|
system. Sent to the remote
|
190 |
|
|
target before GDB
|
191 |
|
|
disconnects.
|
192 |
|
|
reply _no response_ GDB does not check for any
|
193 |
|
|
response after sending this
|
194 |
|
|
packet.
|
195 |
|
|
reserved `e' Reserved for future use
|
196 |
|
|
reserved `E' Reserved for future use
|
197 |
|
|
reserved `f' Reserved for future use
|
198 |
|
|
reserved `F' Reserved for future use
|
199 |
|
|
read registers `g' Read general registers.
|
200 |
|
|
reply XX... Each byte of register data
|
201 |
|
|
is described by two hex
|
202 |
|
|
digits. The bytes with the
|
203 |
|
|
register are transmitted in
|
204 |
|
|
target byte order. The size
|
205 |
|
|
of each register and their
|
206 |
|
|
position within the `g'
|
207 |
|
|
PACKET are determined by the
|
208 |
|
|
GDB internal macros
|
209 |
|
|
REGISTER_RAW_SIZE and
|
210 |
|
|
REGISTER_NAME macros. The
|
211 |
|
|
specification of several
|
212 |
|
|
standard `g' packets is
|
213 |
|
|
specified below.
|
214 |
|
|
`E'NN for an error.
|
215 |
|
|
write regs `G'XX... See `g' for a description of
|
216 |
|
|
the XX... data.
|
217 |
|
|
reply `OK' for success
|
218 |
|
|
reply `E'NN for an error
|
219 |
|
|
reserved `h' Reserved for future use
|
220 |
|
|
set thread `H'CT... Set thread for subsequent
|
221 |
|
|
operations (`m', `M', `g',
|
222 |
|
|
`G', et.al.). C = `c' for
|
223 |
|
|
thread used in step and
|
224 |
|
|
continue; T... can be -1 for
|
225 |
|
|
all threads. C = `g' for
|
226 |
|
|
thread used in other
|
227 |
|
|
operations. If zero, pick a
|
228 |
|
|
thread, any thread.
|
229 |
|
|
reply `OK' for success
|
230 |
|
|
reply `E'NN for an error
|
231 |
|
|
cycle step *(draft)* `i'ADDR`,'NNN Step the remote target by a
|
232 |
|
|
single clock cycle. If
|
233 |
|
|
`,'NNN is present, cycle
|
234 |
|
|
step NNN cycles. If ADDR is
|
235 |
|
|
present, cycle step starting
|
236 |
|
|
at that address.
|
237 |
|
|
signal then cycle `I' See `i' and `S' for likely
|
238 |
|
|
step *(reserved)* syntax and semantics.
|
239 |
|
|
reserved `j' Reserved for future use
|
240 |
|
|
reserved `J' Reserved for future use
|
241 |
|
|
kill request `k' FIXME: _There is no
|
242 |
|
|
description of how operate
|
243 |
|
|
when a specific thread
|
244 |
|
|
context has been selected
|
245 |
|
|
(ie. does 'k' kill only that
|
246 |
|
|
thread?)_.
|
247 |
|
|
reserved `l' Reserved for future use
|
248 |
|
|
reserved `L' Reserved for future use
|
249 |
|
|
read memory `m'ADDR`,'LENGTH Read LENGTH bytes of memory
|
250 |
|
|
starting at address ADDR.
|
251 |
|
|
Neither GDB nor the stub
|
252 |
|
|
assume that sized memory
|
253 |
|
|
transfers are assumed using
|
254 |
|
|
word alligned accesses.
|
255 |
|
|
FIXME: _A word aligned memory
|
256 |
|
|
transfer mechanism is
|
257 |
|
|
needed._
|
258 |
|
|
reply XX... XX... is mem contents. Can
|
259 |
|
|
be fewer bytes than
|
260 |
|
|
requested if able to read
|
261 |
|
|
only part of the data.
|
262 |
|
|
Neither GDB nor the stub
|
263 |
|
|
assume that sized memory
|
264 |
|
|
transfers are assumed using
|
265 |
|
|
word alligned accesses.
|
266 |
|
|
FIXME: _A word aligned
|
267 |
|
|
memory transfer mechanism is
|
268 |
|
|
needed._
|
269 |
|
|
reply `E'NN NN is errno
|
270 |
|
|
write mem `M'ADDR,LENGTH`:'XX... Write LENGTH bytes of memory
|
271 |
|
|
starting at address ADDR.
|
272 |
|
|
XX... is the data.
|
273 |
|
|
reply `OK' for success
|
274 |
|
|
reply `E'NN for an error (this includes
|
275 |
|
|
the case where only part of
|
276 |
|
|
the data was written).
|
277 |
|
|
reserved `n' Reserved for future use
|
278 |
|
|
reserved `N' Reserved for future use
|
279 |
|
|
reserved `o' Reserved for future use
|
280 |
|
|
reserved `O' Reserved for future use
|
281 |
|
|
read reg *(reserved)* `p'N... See write register.
|
282 |
|
|
return R.... The hex encoded value of the
|
283 |
|
|
register in target byte
|
284 |
|
|
order.
|
285 |
|
|
write reg `P'N...`='R... Write register N... with
|
286 |
|
|
value R..., which contains
|
287 |
|
|
two hex digits for each byte
|
288 |
|
|
in the register (target byte
|
289 |
|
|
order).
|
290 |
|
|
reply `OK' for success
|
291 |
|
|
reply `E'NN for an error
|
292 |
|
|
general query `q'QUERY Request info about QUERY.
|
293 |
|
|
In general GDB queries have
|
294 |
|
|
a leading upper case letter.
|
295 |
|
|
Custom vendor queries
|
296 |
|
|
should use a company prefix
|
297 |
|
|
(in lower case) ex:
|
298 |
|
|
`qfsf.var'. QUERY may
|
299 |
|
|
optionally be followed by a
|
300 |
|
|
`,' or `;' separated list.
|
301 |
|
|
Stubs must ensure that they
|
302 |
|
|
match the full QUERY name.
|
303 |
|
|
reply `XX...' Hex encoded data from query.
|
304 |
|
|
The reply can not be empty.
|
305 |
|
|
reply `E'NN error reply
|
306 |
|
|
reply `' Indicating an unrecognized
|
307 |
|
|
QUERY.
|
308 |
|
|
general set `Q'VAR`='VAL Set value of VAR to VAL.
|
309 |
|
|
See `q' for a discussing of
|
310 |
|
|
naming conventions.
|
311 |
|
|
reset *(deprecated)* `r' Reset the entire system.
|
312 |
|
|
remote restart `R'XX Restart the program being
|
313 |
|
|
debugged. XX, while needed,
|
314 |
|
|
is ignored. This packet is
|
315 |
|
|
only available in extended
|
316 |
|
|
mode.
|
317 |
|
|
no reply The `R' packet has no reply.
|
318 |
|
|
step `s'ADDR ADDR is address to resume.
|
319 |
|
|
If ADDR is omitted, resume at
|
320 |
|
|
same address.
|
321 |
|
|
reply see below
|
322 |
|
|
step with signal `S'SIG`;'ADDR Like `C' but step not
|
323 |
|
|
continue.
|
324 |
|
|
reply see below
|
325 |
|
|
search `t'ADDR`:'PP`,'MM Search backwards starting at
|
326 |
|
|
address ADDR for a match
|
327 |
|
|
with pattern PP and mask MM.
|
328 |
|
|
PP and MM are 4 bytes.
|
329 |
|
|
ADDR must be at least 3
|
330 |
|
|
digits.
|
331 |
|
|
thread alive `T'XX Find out if the thread XX is
|
332 |
|
|
alive.
|
333 |
|
|
reply `OK' thread is still alive
|
334 |
|
|
reply `E'NN thread is dead
|
335 |
|
|
reserved `u' Reserved for future use
|
336 |
|
|
reserved `U' Reserved for future use
|
337 |
|
|
reserved `v' Reserved for future use
|
338 |
|
|
reserved `V' Reserved for future use
|
339 |
|
|
reserved `w' Reserved for future use
|
340 |
|
|
reserved `W' Reserved for future use
|
341 |
|
|
reserved `x' Reserved for future use
|
342 |
|
|
write mem (binary) `X'ADDR`,'LENGTH:XX... ADDR is address, LENGTH is
|
343 |
|
|
number of bytes, XX... is
|
344 |
|
|
binary data. The characters
|
345 |
|
|
`$', `#', and `0x7d' are
|
346 |
|
|
escaped using `0x7d'.
|
347 |
|
|
reply `OK' for success
|
348 |
|
|
reply `E'NN for an error
|
349 |
|
|
reserved `y' Reserved for future use
|
350 |
|
|
reserved `Y' Reserved for future use
|
351 |
|
|
remove break or `z'T`,'ADDR`,'LENGTH See `Z'.
|
352 |
|
|
watchpoint *(draft)*
|
353 |
|
|
insert break or `Z'T`,'ADDR`,'LENGTH T is type: `0' - software
|
354 |
|
|
watchpoint *(draft)* breakpoint, `1' - hardware
|
355 |
|
|
breakpoint, `2' - write
|
356 |
|
|
watchpoint, `3' - read
|
357 |
|
|
watchpoint, `4' - access
|
358 |
|
|
watchpoint; ADDR is address;
|
359 |
|
|
LENGTH is in bytes. For a
|
360 |
|
|
software breakpoint, LENGTH
|
361 |
|
|
specifies the size of the
|
362 |
|
|
instruction to be patched.
|
363 |
|
|
For hardware breakpoints and
|
364 |
|
|
watchpoints LENGTH specifies
|
365 |
|
|
the memory region to be
|
366 |
|
|
monitored. To avoid
|
367 |
|
|
potential problems with
|
368 |
|
|
duplicate packets, the
|
369 |
|
|
operations should be
|
370 |
|
|
implemented in an idempotent
|
371 |
|
|
way.
|
372 |
|
|
reply `E'NN for an error
|
373 |
|
|
reply `OK' for success
|
374 |
|
|
`' If not supported.
|
375 |
|
|
reserved Reserved for future use
|
376 |
|
|
|
377 |
|
|
The `C', `c', `S', `s' and `?' packets can receive any of the below
|
378 |
|
|
as a reply. In the case of the `C', `c', `S' and `s' packets, that
|
379 |
|
|
reply is only returned when the target halts. In the below the exact
|
380 |
|
|
meaning of `signal number' is poorly defined. In general one of the
|
381 |
|
|
UNIX signal numbering conventions is used.
|
382 |
|
|
|
383 |
|
|
`S'AA AA is the signal number
|
384 |
|
|
`T'AAN...`:'R...`;'N...`:'R...`;'N...`:'R...`;'AA = two hex digit signal number; N... =
|
385 |
|
|
register number (hex), R... = target byte
|
386 |
|
|
ordered register contents, size defined by
|
387 |
|
|
`REGISTER_RAW_SIZE'; N... = `thread', R...
|
388 |
|
|
= thread process ID, this is a hex
|
389 |
|
|
integer; N... = other string not starting
|
390 |
|
|
with valid hex digit. GDB should ignore
|
391 |
|
|
this N..., R... pair and go on to the
|
392 |
|
|
next. This way we can extend the protocol.
|
393 |
|
|
`W'AA The process exited, and AA is the exit
|
394 |
|
|
status. This is only applicable for
|
395 |
|
|
certains sorts of targets.
|
396 |
|
|
`X'AA The process terminated with signal AA.
|
397 |
|
|
`N'AA`;'T...`;'D...`;'B... AA = signal number; T... = address of
|
398 |
|
|
*(obsolete)* symbol "_start"; D... = base of data
|
399 |
|
|
section; B... = base of bss section.
|
400 |
|
|
_Note: only used by Cisco Systems targets.
|
401 |
|
|
The difference between this reply and the
|
402 |
|
|
"qOffsets" query is that the 'N' packet
|
403 |
|
|
may arrive spontaneously whereas the
|
404 |
|
|
'qOffsets' is a query initiated by the host
|
405 |
|
|
debugger._
|
406 |
|
|
`O'XX... XX... is hex encoding of ASCII data. This
|
407 |
|
|
can happen at any time while the program
|
408 |
|
|
is running and the debugger should
|
409 |
|
|
continue to wait for 'W', 'T', etc.
|
410 |
|
|
|
411 |
|
|
The following set and query packets have already been defined.
|
412 |
|
|
|
413 |
|
|
current thread `q'`C' Return the current thread id.
|
414 |
|
|
reply `QC'PID Where PID is a HEX encoded 16 bit process
|
415 |
|
|
id.
|
416 |
|
|
reply * Any other reply implies the old pid.
|
417 |
|
|
all thread ids `q'`fThreadInfo'
|
418 |
|
|
`q'`sThreadInfo'Obtain a list of active thread ids from
|
419 |
|
|
the target (OS). Since there may be too
|
420 |
|
|
many active threads to fit into one reply
|
421 |
|
|
packet, this query works iteratively: it
|
422 |
|
|
may require more than one query/reply
|
423 |
|
|
sequence to obtain the entire list of
|
424 |
|
|
threads. The first query of the sequence
|
425 |
|
|
will be the `qf'`ThreadInfo' query;
|
426 |
|
|
subsequent queries in the sequence will be
|
427 |
|
|
the `qs'`ThreadInfo' query.
|
428 |
|
|
NOTE: replaces the `qL' query (see below).
|
429 |
|
|
reply `m' A single thread id
|
430 |
|
|
reply a comma-separated list of thread ids
|
431 |
|
|
`m',...
|
432 |
|
|
reply `l' (lower case 'el') denotes end of list.
|
433 |
|
|
In response to each query, the target will
|
434 |
|
|
reply with a list of one or more thread
|
435 |
|
|
ids, in big-endian hex, separated by
|
436 |
|
|
commas. GDB will respond to each reply
|
437 |
|
|
with a request for more thread ids (using
|
438 |
|
|
the `qs' form of the query), until the
|
439 |
|
|
target responds with `l' (lower-case el,
|
440 |
|
|
for `'last'').
|
441 |
|
|
extra thread `q'`ThreadExtraInfo'`,'ID
|
442 |
|
|
info
|
443 |
|
|
Where is a thread-id in big-endian
|
444 |
|
|
hex. Obtain a printable string
|
445 |
|
|
description of a thread's attributes from
|
446 |
|
|
the target OS. This string may contain
|
447 |
|
|
anything that the target OS thinks is
|
448 |
|
|
interesting for GDB to tell the user about
|
449 |
|
|
the thread. The string is displayed in
|
450 |
|
|
GDB's `info threads' display. Some
|
451 |
|
|
examples of possible thread extra info
|
452 |
|
|
strings are "Runnable", or "Blocked on
|
453 |
|
|
Mutex".
|
454 |
|
|
reply XX... Where XX... is a hex encoding of ASCII
|
455 |
|
|
data, comprising the printable string
|
456 |
|
|
containing the extra information about the
|
457 |
|
|
thread's attributes.
|
458 |
|
|
query LIST or `q'`L'STARTFLAGTHREADCOUNTNEXTTHREAD
|
459 |
|
|
THREADLIST
|
460 |
|
|
*(deprecated)*
|
461 |
|
|
Obtain thread information from RTOS.
|
462 |
|
|
Where: STARTFLAG (one hex digit) is one to
|
463 |
|
|
indicate the first query and zero to
|
464 |
|
|
indicate a subsequent query; THREADCOUNT
|
465 |
|
|
(two hex digits) is the maximum number of
|
466 |
|
|
threads the response packet can contain;
|
467 |
|
|
and NEXTTHREAD (eight hex digits), for
|
468 |
|
|
subsequent queries (STARTFLAG is zero), is
|
469 |
|
|
returned in the response as ARGTHREAD.
|
470 |
|
|
NOTE: this query is replaced by the
|
471 |
|
|
`q'`fThreadInfo' query (see above).
|
472 |
|
|
reply
|
473 |
|
|
`q'`M'COUNTDONEARGTHREADTHREAD...
|
474 |
|
|
Where: COUNT (two hex digits) is the
|
475 |
|
|
number of threads being returned; DONE
|
476 |
|
|
(one hex digit) is zero to indicate more
|
477 |
|
|
threads and one indicates no further
|
478 |
|
|
threads; ARGTHREADID (eight hex digits) is
|
479 |
|
|
NEXTTHREAD from the request packet;
|
480 |
|
|
THREAD... is a sequence of thread IDs from
|
481 |
|
|
the target. THREADID (eight hex digits).
|
482 |
|
|
See `remote.c:parse_threadlist_response()'.
|
483 |
|
|
compute CRC `q'`CRC:'ADDR`,'LENGTH
|
484 |
|
|
of memory
|
485 |
|
|
block
|
486 |
|
|
reply `E'NN An error (such as memory fault)
|
487 |
|
|
reply `C'CRC32 A 32 bit cyclic redundancy check of the
|
488 |
|
|
specified memory region.
|
489 |
|
|
query sect `q'`Offsets' Get section offsets that the target used
|
490 |
|
|
offs when re-locating the downloaded image.
|
491 |
|
|
_Note: while a `Bss' offset is included in
|
492 |
|
|
the response, GDB ignores this and instead
|
493 |
|
|
applies the `Data' offset to the `Bss'
|
494 |
|
|
section._
|
495 |
|
|
reply
|
496 |
|
|
`Text='XXX`;Data='YYY`;Bss='ZZZ
|
497 |
|
|
thread info `q'`P'MODETHREADID
|
498 |
|
|
request
|
499 |
|
|
Returns information on THREADID. Where:
|
500 |
|
|
MODE is a hex encoded 32 bit mode;
|
501 |
|
|
THREADID is a hex encoded 64 bit thread ID.
|
502 |
|
|
reply * See
|
503 |
|
|
`remote.c:remote_unpack_thread_info_response()'.
|
504 |
|
|
remote command `q'`Rcmd,'COMMAND
|
505 |
|
|
COMMAND (hex encoded) is passed to the
|
506 |
|
|
local interpreter for execution. Invalid
|
507 |
|
|
commands should be reported using the
|
508 |
|
|
output string. Before the final result
|
509 |
|
|
packet, the target may also respond with a
|
510 |
|
|
number of intermediate `O'OUTPUT console
|
511 |
|
|
output packets. _Implementors should note
|
512 |
|
|
that providing access to a stubs's
|
513 |
|
|
interpreter may have security
|
514 |
|
|
implications_.
|
515 |
|
|
reply `OK' A command response with no output.
|
516 |
|
|
reply OUTPUT A command response with the hex encoded
|
517 |
|
|
output string OUTPUT.
|
518 |
|
|
reply `E'NN Indicate a badly formed request.
|
519 |
|
|
reply `' When `q'`Rcmd' is not recognized.
|
520 |
|
|
symbol lookup `qSymbol::' Notify the target that GDB is prepared to
|
521 |
|
|
serve symbol lookup requests. Accept
|
522 |
|
|
requests from the target for the values of
|
523 |
|
|
symbols.
|
524 |
|
|
|
525 |
|
|
reply `OK' The target does not need to look up any
|
526 |
|
|
(more) symbols.
|
527 |
|
|
reply The target requests the value of symbol
|
528 |
|
|
`qSymbol:'SYM_NAMESYM_NAME (hex encoded). GDB may provide
|
529 |
|
|
the value by using the
|
530 |
|
|
`qSymbol:'SYM_VALUE:SYM_NAME message,
|
531 |
|
|
described below.
|
532 |
|
|
symbol value `qSymbol:'SYM_VALUE:SYM_NAMESet the value of SYM_NAME to SYM_VALUE.
|
533 |
|
|
SYM_NAME (hex encoded) is the name of a
|
534 |
|
|
symbol whose value the target has
|
535 |
|
|
previously requested.
|
536 |
|
|
SYM_VALUE (hex) is the value for symbol
|
537 |
|
|
SYM_NAME. If GDB cannot supply a value
|
538 |
|
|
for SYM_NAME, then this field will be
|
539 |
|
|
empty.
|
540 |
|
|
reply `OK' The target does not need to look up any
|
541 |
|
|
(more) symbols.
|
542 |
|
|
reply The target requests the value of a new
|
543 |
|
|
`qSymbol:'SYM_NAMEsymbol SYM_NAME (hex encoded). GDB will
|
544 |
|
|
continue to supply the values of symbols
|
545 |
|
|
(if available), until the target ceases to
|
546 |
|
|
request them.
|
547 |
|
|
|
548 |
|
|
The following `g'/`G' packets have previously been defined. In the
|
549 |
|
|
below, some thirty-two bit registers are transferred as sixty-four
|
550 |
|
|
bits. Those registers should be zero/sign extended (which?) to fill the
|
551 |
|
|
space allocated. Register bytes are transfered in target byte order.
|
552 |
|
|
The two nibbles within a register byte are transfered most-significant -
|
553 |
|
|
least-significant.
|
554 |
|
|
|
555 |
|
|
MIPS32 All registers are transfered as
|
556 |
|
|
thirty-two bit quantities in the
|
557 |
|
|
order: 32 general-purpose; sr; lo;
|
558 |
|
|
hi; bad; cause; pc; 32
|
559 |
|
|
floating-point registers; fsr; fir;
|
560 |
|
|
fp.
|
561 |
|
|
MIPS64 All registers are transfered as
|
562 |
|
|
sixty-four bit quantities (including
|
563 |
|
|
thirty-two bit registers such as
|
564 |
|
|
`sr'). The ordering is the same as
|
565 |
|
|
`MIPS32'.
|
566 |
|
|
|
567 |
|
|
Example sequence of a target being re-started. Notice how the
|
568 |
|
|
restart does not get any direct output:
|
569 |
|
|
|
570 |
|
|
<- `R00'
|
571 |
|
|
-> `+'
|
572 |
|
|
_target restarts_
|
573 |
|
|
<- `?'
|
574 |
|
|
-> `+'
|
575 |
|
|
-> `T001:1234123412341234'
|
576 |
|
|
<- `+'
|
577 |
|
|
|
578 |
|
|
Example sequence of a target being stepped by a single instruction:
|
579 |
|
|
|
580 |
|
|
<- `G1445...'
|
581 |
|
|
-> `+'
|
582 |
|
|
<- `s'
|
583 |
|
|
-> `+'
|
584 |
|
|
_time passes_
|
585 |
|
|
-> `T001:1234123412341234'
|
586 |
|
|
<- `+'
|
587 |
|
|
<- `g'
|
588 |
|
|
-> `+'
|
589 |
|
|
-> `1455...'
|
590 |
|
|
<- `+'
|
591 |
|
|
|
592 |
|
|
|
593 |
|
|
File: gdb.info, Node: Server, Next: NetWare, Prev: Protocol, Up: Remote Serial
|
594 |
|
|
|
595 |
|
|
Using the `gdbserver' program
|
596 |
|
|
.............................
|
597 |
|
|
|
598 |
|
|
`gdbserver' is a control program for Unix-like systems, which allows
|
599 |
|
|
you to connect your program with a remote GDB via `target remote'--but
|
600 |
|
|
without linking in the usual debugging stub.
|
601 |
|
|
|
602 |
|
|
`gdbserver' is not a complete replacement for the debugging stubs,
|
603 |
|
|
because it requires essentially the same operating-system facilities
|
604 |
|
|
that GDB itself does. In fact, a system that can run `gdbserver' to
|
605 |
|
|
connect to a remote GDB could also run GDB locally! `gdbserver' is
|
606 |
|
|
sometimes useful nevertheless, because it is a much smaller program
|
607 |
|
|
than GDB itself. It is also easier to port than all of GDB, so you may
|
608 |
|
|
be able to get started more quickly on a new system by using
|
609 |
|
|
`gdbserver'. Finally, if you develop code for real-time systems, you
|
610 |
|
|
may find that the tradeoffs involved in real-time operation make it
|
611 |
|
|
more convenient to do as much development work as possible on another
|
612 |
|
|
system, for example by cross-compiling. You can use `gdbserver' to
|
613 |
|
|
make a similar choice for debugging.
|
614 |
|
|
|
615 |
|
|
GDB and `gdbserver' communicate via either a serial line or a TCP
|
616 |
|
|
connection, using the standard GDB remote serial protocol.
|
617 |
|
|
|
618 |
|
|
_On the target machine,_
|
619 |
|
|
you need to have a copy of the program you want to debug.
|
620 |
|
|
`gdbserver' does not need your program's symbol table, so you can
|
621 |
|
|
strip the program if necessary to save space. GDB on the host
|
622 |
|
|
system does all the symbol handling.
|
623 |
|
|
|
624 |
|
|
To use the server, you must tell it how to communicate with GDB;
|
625 |
|
|
the name of your program; and the arguments for your program. The
|
626 |
|
|
syntax is:
|
627 |
|
|
|
628 |
|
|
target> gdbserver COMM PROGRAM [ ARGS ... ]
|
629 |
|
|
|
630 |
|
|
COMM is either a device name (to use a serial line) or a TCP
|
631 |
|
|
hostname and portnumber. For example, to debug Emacs with the
|
632 |
|
|
argument `foo.txt' and communicate with GDB over the serial port
|
633 |
|
|
`/dev/com1':
|
634 |
|
|
|
635 |
|
|
target> gdbserver /dev/com1 emacs foo.txt
|
636 |
|
|
|
637 |
|
|
`gdbserver' waits passively for the host GDB to communicate with
|
638 |
|
|
it.
|
639 |
|
|
|
640 |
|
|
To use a TCP connection instead of a serial line:
|
641 |
|
|
|
642 |
|
|
target> gdbserver host:2345 emacs foo.txt
|
643 |
|
|
|
644 |
|
|
The only difference from the previous example is the first
|
645 |
|
|
argument, specifying that you are communicating with the host GDB
|
646 |
|
|
via TCP. The `host:2345' argument means that `gdbserver' is to
|
647 |
|
|
expect a TCP connection from machine `host' to local TCP port 2345.
|
648 |
|
|
(Currently, the `host' part is ignored.) You can choose any number
|
649 |
|
|
you want for the port number as long as it does not conflict with
|
650 |
|
|
any TCP ports already in use on the target system (for example,
|
651 |
|
|
`23' is reserved for `telnet').(1) You must use the same port
|
652 |
|
|
number with the host GDB `target remote' command.
|
653 |
|
|
|
654 |
|
|
_On the GDB host machine,_
|
655 |
|
|
you need an unstripped copy of your program, since GDB needs
|
656 |
|
|
symbols and debugging information. Start up GDB as usual, using
|
657 |
|
|
the name of the local copy of your program as the first argument.
|
658 |
|
|
(You may also need the `--baud' option if the serial line is
|
659 |
|
|
running at anything other than 9600bps.) After that, use `target
|
660 |
|
|
remote' to establish communications with `gdbserver'. Its argument
|
661 |
|
|
is either a device name (usually a serial device, like
|
662 |
|
|
`/dev/ttyb'), or a TCP port descriptor in the form `HOST:PORT'.
|
663 |
|
|
For example:
|
664 |
|
|
|
665 |
|
|
(gdb) target remote /dev/ttyb
|
666 |
|
|
|
667 |
|
|
communicates with the server via serial line `/dev/ttyb', and
|
668 |
|
|
|
669 |
|
|
(gdb) target remote the-target:2345
|
670 |
|
|
|
671 |
|
|
communicates via a TCP connection to port 2345 on host
|
672 |
|
|
`the-target'. For TCP connections, you must start up `gdbserver'
|
673 |
|
|
prior to using the `target remote' command. Otherwise you may get
|
674 |
|
|
an error whose text depends on the host system, but which usually
|
675 |
|
|
looks something like `Connection refused'.
|
676 |
|
|
|
677 |
|
|
---------- Footnotes ----------
|
678 |
|
|
|
679 |
|
|
(1) If you choose a port number that conflicts with another service,
|
680 |
|
|
`gdbserver' prints an error message and exits.
|
681 |
|
|
|
682 |
|
|
|
683 |
|
|
File: gdb.info, Node: NetWare, Prev: Server, Up: Remote Serial
|
684 |
|
|
|
685 |
|
|
Using the `gdbserve.nlm' program
|
686 |
|
|
................................
|
687 |
|
|
|
688 |
|
|
`gdbserve.nlm' is a control program for NetWare systems, which
|
689 |
|
|
allows you to connect your program with a remote GDB via `target
|
690 |
|
|
remote'.
|
691 |
|
|
|
692 |
|
|
GDB and `gdbserve.nlm' communicate via a serial line, using the
|
693 |
|
|
standard GDB remote serial protocol.
|
694 |
|
|
|
695 |
|
|
_On the target machine,_
|
696 |
|
|
you need to have a copy of the program you want to debug.
|
697 |
|
|
`gdbserve.nlm' does not need your program's symbol table, so you
|
698 |
|
|
can strip the program if necessary to save space. GDB on the host
|
699 |
|
|
system does all the symbol handling.
|
700 |
|
|
|
701 |
|
|
To use the server, you must tell it how to communicate with GDB;
|
702 |
|
|
the name of your program; and the arguments for your program. The
|
703 |
|
|
syntax is:
|
704 |
|
|
|
705 |
|
|
load gdbserve [ BOARD=BOARD ] [ PORT=PORT ]
|
706 |
|
|
[ BAUD=BAUD ] PROGRAM [ ARGS ... ]
|
707 |
|
|
|
708 |
|
|
BOARD and PORT specify the serial line; BAUD specifies the baud
|
709 |
|
|
rate used by the connection. PORT and NODE default to 0, BAUD
|
710 |
|
|
defaults to 9600bps.
|
711 |
|
|
|
712 |
|
|
For example, to debug Emacs with the argument `foo.txt'and
|
713 |
|
|
communicate with GDB over serial port number 2 or board 1 using a
|
714 |
|
|
19200bps connection:
|
715 |
|
|
|
716 |
|
|
load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt
|
717 |
|
|
|
718 |
|
|
_On the GDB host machine,_
|
719 |
|
|
you need an unstripped copy of your program, since GDB needs
|
720 |
|
|
symbols and debugging information. Start up GDB as usual, using
|
721 |
|
|
the name of the local copy of your program as the first argument.
|
722 |
|
|
(You may also need the `--baud' option if the serial line is
|
723 |
|
|
running at anything other than 9600bps. After that, use `target
|
724 |
|
|
remote' to establish communications with `gdbserve.nlm'. Its
|
725 |
|
|
argument is a device name (usually a serial device, like
|
726 |
|
|
`/dev/ttyb'). For example:
|
727 |
|
|
|
728 |
|
|
(gdb) target remote /dev/ttyb
|
729 |
|
|
|
730 |
|
|
communications with the server via serial line `/dev/ttyb'.
|
731 |
|
|
|
732 |
|
|
|
733 |
|
|
File: gdb.info, Node: KOD, Prev: Remote, Up: Targets
|
734 |
|
|
|
735 |
|
|
Kernel Object Display
|
736 |
|
|
=====================
|
737 |
|
|
|
738 |
|
|
Some targets support kernel object display. Using this facility,
|
739 |
|
|
GDB communicates specially with the underlying operating system and can
|
740 |
|
|
display information about operating system-level objects such as
|
741 |
|
|
mutexes and other synchronization objects. Exactly which objects can be
|
742 |
|
|
displayed is determined on a per-OS basis.
|
743 |
|
|
|
744 |
|
|
Use the `set os' command to set the operating system. This tells
|
745 |
|
|
GDB which kernel object display module to initialize:
|
746 |
|
|
|
747 |
|
|
(gdb) set os cisco
|
748 |
|
|
|
749 |
|
|
If `set os' succeeds, GDB will display some information about the
|
750 |
|
|
operating system, and will create a new `info' command which can be
|
751 |
|
|
used to query the target. The `info' command is named after the
|
752 |
|
|
operating system:
|
753 |
|
|
|
754 |
|
|
(gdb) info cisco
|
755 |
|
|
List of Cisco Kernel Objects
|
756 |
|
|
Object Description
|
757 |
|
|
any Any and all objects
|
758 |
|
|
|
759 |
|
|
Further subcommands can be used to query about particular objects
|
760 |
|
|
known by the kernel.
|
761 |
|
|
|
762 |
|
|
There is currently no way to determine whether a given operating
|
763 |
|
|
system is supported other than to try it.
|
764 |
|
|
|
765 |
|
|
|
766 |
|
|
File: gdb.info, Node: Configurations, Next: Controlling GDB, Prev: Targets, Up: Top
|
767 |
|
|
|
768 |
|
|
Configuration-Specific Information
|
769 |
|
|
**********************************
|
770 |
|
|
|
771 |
|
|
While nearly all GDB commands are available for all native and cross
|
772 |
|
|
versions of the debugger, there are some exceptions. This chapter
|
773 |
|
|
describes things that are only available in certain configurations.
|
774 |
|
|
|
775 |
|
|
There are three major categories of configurations: native
|
776 |
|
|
configurations, where the host and target are the same, embedded
|
777 |
|
|
operating system configurations, which are usually the same for several
|
778 |
|
|
different processor architectures, and bare embedded processors, which
|
779 |
|
|
are quite different from each other.
|
780 |
|
|
|
781 |
|
|
* Menu:
|
782 |
|
|
|
783 |
|
|
* Native::
|
784 |
|
|
* Embedded OS::
|
785 |
|
|
* Embedded Processors::
|
786 |
|
|
* Architectures::
|
787 |
|
|
|
788 |
|
|
|
789 |
|
|
File: gdb.info, Node: Native, Next: Embedded OS, Up: Configurations
|
790 |
|
|
|
791 |
|
|
Native
|
792 |
|
|
======
|
793 |
|
|
|
794 |
|
|
This section describes details specific to particular native
|
795 |
|
|
configurations.
|
796 |
|
|
|
797 |
|
|
* Menu:
|
798 |
|
|
|
799 |
|
|
* HP-UX:: HP-UX
|
800 |
|
|
* SVR4 Process Information:: SVR4 process information
|
801 |
|
|
|
802 |
|
|
|
803 |
|
|
File: gdb.info, Node: HP-UX, Next: SVR4 Process Information, Up: Native
|
804 |
|
|
|
805 |
|
|
HP-UX
|
806 |
|
|
-----
|
807 |
|
|
|
808 |
|
|
On HP-UX systems, if you refer to a function or variable name that
|
809 |
|
|
begins with a dollar sign, GDB searches for a user or system name
|
810 |
|
|
first, before it searches for a convenience variable.
|
811 |
|
|
|
812 |
|
|
|
813 |
|
|
File: gdb.info, Node: SVR4 Process Information, Prev: HP-UX, Up: Native
|
814 |
|
|
|
815 |
|
|
SVR4 process information
|
816 |
|
|
------------------------
|
817 |
|
|
|
818 |
|
|
Many versions of SVR4 provide a facility called `/proc' that can be
|
819 |
|
|
used to examine the image of a running process using file-system
|
820 |
|
|
subroutines. If GDB is configured for an operating system with this
|
821 |
|
|
facility, the command `info proc' is available to report on several
|
822 |
|
|
kinds of information about the process running your program. `info
|
823 |
|
|
proc' works only on SVR4 systems that include the `procfs' code. This
|
824 |
|
|
includes OSF/1 (Digital Unix), Solaris, Irix, and Unixware, but not
|
825 |
|
|
HP-UX or Linux, for example.
|
826 |
|
|
|
827 |
|
|
`info proc'
|
828 |
|
|
Summarize available information about the process.
|
829 |
|
|
|
830 |
|
|
`info proc mappings'
|
831 |
|
|
Report on the address ranges accessible in the program, with
|
832 |
|
|
information on whether your program may read, write, or execute
|
833 |
|
|
each range.
|
834 |
|
|
|
835 |
|
|
`info proc times'
|
836 |
|
|
Starting time, user CPU time, and system CPU time for your program
|
837 |
|
|
and its children.
|
838 |
|
|
|
839 |
|
|
`info proc id'
|
840 |
|
|
Report on the process IDs related to your program: its own process
|
841 |
|
|
ID, the ID of its parent, the process group ID, and the session ID.
|
842 |
|
|
|
843 |
|
|
`info proc status'
|
844 |
|
|
General information on the state of the process. If the process is
|
845 |
|
|
stopped, this report includes the reason for stopping, and any
|
846 |
|
|
signal received.
|
847 |
|
|
|
848 |
|
|
`info proc all'
|
849 |
|
|
Show all the above information about the process.
|
850 |
|
|
|
851 |
|
|
|
852 |
|
|
File: gdb.info, Node: Embedded OS, Next: Embedded Processors, Prev: Native, Up: Configurations
|
853 |
|
|
|
854 |
|
|
Embedded Operating Systems
|
855 |
|
|
==========================
|
856 |
|
|
|
857 |
|
|
This section describes configurations involving the debugging of
|
858 |
|
|
embedded operating systems that are available for several different
|
859 |
|
|
architectures.
|
860 |
|
|
|
861 |
|
|
* Menu:
|
862 |
|
|
|
863 |
|
|
* VxWorks:: Using GDB with VxWorks
|
864 |
|
|
|
865 |
|
|
GDB includes the ability to debug programs running on various
|
866 |
|
|
real-time operating systems.
|
867 |
|
|
|
868 |
|
|
|
869 |
|
|
File: gdb.info, Node: VxWorks, Up: Embedded OS
|
870 |
|
|
|
871 |
|
|
Using GDB with VxWorks
|
872 |
|
|
----------------------
|
873 |
|
|
|
874 |
|
|
`target vxworks MACHINENAME'
|
875 |
|
|
A VxWorks system, attached via TCP/IP. The argument MACHINENAME
|
876 |
|
|
is the target system's machine name or IP address.
|
877 |
|
|
|
878 |
|
|
On VxWorks, `load' links FILENAME dynamically on the current target
|
879 |
|
|
system as well as adding its symbols in GDB.
|
880 |
|
|
|
881 |
|
|
GDB enables developers to spawn and debug tasks running on networked
|
882 |
|
|
VxWorks targets from a Unix host. Already-running tasks spawned from
|
883 |
|
|
the VxWorks shell can also be debugged. GDB uses code that runs on
|
884 |
|
|
both the Unix host and on the VxWorks target. The program `gdb' is
|
885 |
|
|
installed and executed on the Unix host. (It may be installed with the
|
886 |
|
|
name `vxgdb', to distinguish it from a GDB for debugging programs on
|
887 |
|
|
the host itself.)
|
888 |
|
|
|
889 |
|
|
`VxWorks-timeout ARGS'
|
890 |
|
|
All VxWorks-based targets now support the option `vxworks-timeout'.
|
891 |
|
|
This option is set by the user, and ARGS represents the number of
|
892 |
|
|
seconds GDB waits for responses to rpc's. You might use this if
|
893 |
|
|
your VxWorks target is a slow software simulator or is on the far
|
894 |
|
|
side of a thin network line.
|
895 |
|
|
|
896 |
|
|
The following information on connecting to VxWorks was current when
|
897 |
|
|
this manual was produced; newer releases of VxWorks may use revised
|
898 |
|
|
procedures.
|
899 |
|
|
|
900 |
|
|
To use GDB with VxWorks, you must rebuild your VxWorks kernel to
|
901 |
|
|
include the remote debugging interface routines in the VxWorks library
|
902 |
|
|
`rdb.a'. To do this, define `INCLUDE_RDB' in the VxWorks configuration
|
903 |
|
|
file `configAll.h' and rebuild your VxWorks kernel. The resulting
|
904 |
|
|
kernel contains `rdb.a', and spawns the source debugging task
|
905 |
|
|
`tRdbTask' when VxWorks is booted. For more information on configuring
|
906 |
|
|
and remaking VxWorks, see the manufacturer's manual.
|
907 |
|
|
|
908 |
|
|
Once you have included `rdb.a' in your VxWorks system image and set
|
909 |
|
|
your Unix execution search path to find GDB, you are ready to run GDB.
|
910 |
|
|
From your Unix host, run `gdb' (or `vxgdb', depending on your
|
911 |
|
|
installation).
|
912 |
|
|
|
913 |
|
|
GDB comes up showing the prompt:
|
914 |
|
|
|
915 |
|
|
(vxgdb)
|
916 |
|
|
|
917 |
|
|
* Menu:
|
918 |
|
|
|
919 |
|
|
* VxWorks Connection:: Connecting to VxWorks
|
920 |
|
|
* VxWorks Download:: VxWorks download
|
921 |
|
|
* VxWorks Attach:: Running tasks
|
922 |
|
|
|
923 |
|
|
|
924 |
|
|
File: gdb.info, Node: VxWorks Connection, Next: VxWorks Download, Up: VxWorks
|
925 |
|
|
|
926 |
|
|
Connecting to VxWorks
|
927 |
|
|
.....................
|
928 |
|
|
|
929 |
|
|
The GDB command `target' lets you connect to a VxWorks target on the
|
930 |
|
|
network. To connect to a target whose host name is "`tt'", type:
|
931 |
|
|
|
932 |
|
|
(vxgdb) target vxworks tt
|
933 |
|
|
|
934 |
|
|
GDB displays messages like these:
|
935 |
|
|
|
936 |
|
|
Attaching remote machine across net...
|
937 |
|
|
Connected to tt.
|
938 |
|
|
|
939 |
|
|
GDB then attempts to read the symbol tables of any object modules
|
940 |
|
|
loaded into the VxWorks target since it was last booted. GDB locates
|
941 |
|
|
these files by searching the directories listed in the command search
|
942 |
|
|
path (*note Your program's environment: Environment.); if it fails to
|
943 |
|
|
find an object file, it displays a message such as:
|
944 |
|
|
|
945 |
|
|
prog.o: No such file or directory.
|
946 |
|
|
|
947 |
|
|
When this happens, add the appropriate directory to the search path
|
948 |
|
|
with the GDB command `path', and execute the `target' command again.
|
949 |
|
|
|
950 |
|
|
|
951 |
|
|
File: gdb.info, Node: VxWorks Download, Next: VxWorks Attach, Prev: VxWorks Connection, Up: VxWorks
|
952 |
|
|
|
953 |
|
|
VxWorks download
|
954 |
|
|
................
|
955 |
|
|
|
956 |
|
|
If you have connected to the VxWorks target and you want to debug an
|
957 |
|
|
object that has not yet been loaded, you can use the GDB `load' command
|
958 |
|
|
to download a file from Unix to VxWorks incrementally. The object file
|
959 |
|
|
given as an argument to the `load' command is actually opened twice:
|
960 |
|
|
first by the VxWorks target in order to download the code, then by GDB
|
961 |
|
|
in order to read the symbol table. This can lead to problems if the
|
962 |
|
|
current working directories on the two systems differ. If both systems
|
963 |
|
|
have NFS mounted the same filesystems, you can avoid these problems by
|
964 |
|
|
using absolute paths. Otherwise, it is simplest to set the working
|
965 |
|
|
directory on both systems to the directory in which the object file
|
966 |
|
|
resides, and then to reference the file by its name, without any path.
|
967 |
|
|
For instance, a program `prog.o' may reside in `VXPATH/vw/demo/rdb' in
|
968 |
|
|
VxWorks and in `HOSTPATH/vw/demo/rdb' on the host. To load this
|
969 |
|
|
program, type this on VxWorks:
|
970 |
|
|
|
971 |
|
|
-> cd "VXPATH/vw/demo/rdb"
|
972 |
|
|
|
973 |
|
|
Then, in GDB, type:
|
974 |
|
|
|
975 |
|
|
(vxgdb) cd HOSTPATH/vw/demo/rdb
|
976 |
|
|
(vxgdb) load prog.o
|
977 |
|
|
|
978 |
|
|
GDB displays a response similar to this:
|
979 |
|
|
|
980 |
|
|
Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
|
981 |
|
|
|
982 |
|
|
You can also use the `load' command to reload an object module after
|
983 |
|
|
editing and recompiling the corresponding source file. Note that this
|
984 |
|
|
makes GDB delete all currently-defined breakpoints, auto-displays, and
|
985 |
|
|
convenience variables, and to clear the value history. (This is
|
986 |
|
|
necessary in order to preserve the integrity of debugger's data
|
987 |
|
|
structures that reference the target system's symbol table.)
|
988 |
|
|
|
989 |
|
|
|
990 |
|
|
File: gdb.info, Node: VxWorks Attach, Prev: VxWorks Download, Up: VxWorks
|
991 |
|
|
|
992 |
|
|
Running tasks
|
993 |
|
|
.............
|
994 |
|
|
|
995 |
|
|
You can also attach to an existing task using the `attach' command as
|
996 |
|
|
follows:
|
997 |
|
|
|
998 |
|
|
(vxgdb) attach TASK
|
999 |
|
|
|
1000 |
|
|
where TASK is the VxWorks hexadecimal task ID. The task can be running
|
1001 |
|
|
or suspended when you attach to it. Running tasks are suspended at the
|
1002 |
|
|
time of attachment.
|
1003 |
|
|
|
1004 |
|
|
|
1005 |
|
|
File: gdb.info, Node: Embedded Processors, Next: Architectures, Prev: Embedded OS, Up: Configurations
|
1006 |
|
|
|
1007 |
|
|
Embedded Processors
|
1008 |
|
|
===================
|
1009 |
|
|
|
1010 |
|
|
This section goes into details specific to particular embedded
|
1011 |
|
|
configurations.
|
1012 |
|
|
|
1013 |
|
|
* Menu:
|
1014 |
|
|
|
1015 |
|
|
* A29K Embedded:: AMD A29K Embedded
|
1016 |
|
|
* ARM:: ARM
|
1017 |
|
|
* H8/300:: Hitachi H8/300
|
1018 |
|
|
* H8/500:: Hitachi H8/500
|
1019 |
|
|
* i960:: Intel i960
|
1020 |
|
|
* M32R/D:: Mitsubishi M32R/D
|
1021 |
|
|
* M68K:: Motorola M68K
|
1022 |
|
|
* M88K:: Motorola M88K
|
1023 |
|
|
* MIPS Embedded:: MIPS Embedded
|
1024 |
|
|
* PA:: HP PA Embedded
|
1025 |
|
|
* PowerPC: PowerPC
|
1026 |
|
|
* SH:: Hitachi SH
|
1027 |
|
|
* Sparclet:: Tsqware Sparclet
|
1028 |
|
|
* Sparclite:: Fujitsu Sparclite
|
1029 |
|
|
* ST2000:: Tandem ST2000
|
1030 |
|
|
* Z8000:: Zilog Z8000
|
1031 |
|
|
|