Chapter 20. Configuration-Specific Information
167
To use gdb with VxWorks, you must rebuild your VxWorks kernel to include the remote debugging
interface routines in the VxWorks library
rdb.a
. To do this, define
INCLUDE_RDB
in the VxWorks
configuration file
configAll.h
and rebuild your VxWorks kernel. The resulting kernel contains
rdb.a
, and spawns the source debugging task
tRdbTask
when VxWorks is booted. For more infor-
mation on configuring and remaking VxWorks, see the manufacturer’s manual.
Once you have included
rdb.a
in your VxWorks system image and set your Unix execution search
path to find gdb, you are ready to run gdb. From your Unix host, run
gdb
(or
vxgdb
, depending on
your installation).
gdb comes up showing the prompt:
(vxgdb)
20.2.1.1. Connecting to VxWorks
The gdb command
target
lets you connect to a VxWorks target on the network. To connect to a
target whose host name is "
tt
", type:
(vxgdb) target vxworks tt
gdb displays messages like these:
Attaching remote machine across net...
Connected to tt.
gdb then attempts to read the symbol tables of any object modules loaded into the VxWorks target
since it was last booted. gdb locates these files by searching the directories listed in the command
search path (refer to Section 6.4
Your program’s environment
); if it fails to find an object file, it
displays a message such as:
prog.o: No such file or directory.
When this happens, add the appropriate directory to the search path with the gdb command
path
, and
execute the
target
command again.
20.2.1.2. VxWorks download
If you have connected to the VxWorks target and you want to debug an object that has not yet been
loaded, you can use the gdb
load
command to download a file from Unix to VxWorks incrementally.
The object file given as an argument to the
load
command is actually opened twice: first by the
VxWorks target in order to download the code, then by gdb in order to read the symbol table. This can
lead to problems if the current working directories on the two systems differ. If both systems have NFS
mounted the same filesystems, you can avoid these problems by using absolute paths. Otherwise, it is
simplest to set the working directory on both systems to the directory in which the object file resides,
and then to reference the file by its name, without any path. For instance, a program
prog.o
may
reside in
vxpath
/vw/demo/rdb
in VxWorks and in
hostpath
/vw/demo/rdb
on the host. To load
this program, type this on VxWorks:
Summary of Contents for ENTERPRISE LINUX 4 - DEVELOPER TOOLS GUIDE
Page 1: ...Red Hat Enterprise Linux 4 Debugging with gdb ...
Page 12: ...2 Chapter 1 Debugging with gdb ...
Page 28: ...18 Chapter 4 Getting In and Out of gdb ...
Page 34: ...24 Chapter 5 gdb Commands ...
Page 44: ...34 Chapter 6 Running Programs Under gdb ...
Page 68: ...58 Chapter 8 Examining the Stack ...
Page 98: ...88 Chapter 10 Examining Data ...
Page 112: ...102 Chapter 12 Tracepoints ...
Page 118: ...108 Chapter 13 Debugging Programs That Use Overlays ...
Page 138: ...128 Chapter 14 Using gdb with Different Languages ...
Page 144: ...134 Chapter 15 Examining the Symbol Table ...
Page 170: ...160 Chapter 19 Debugging remote programs ...
Page 198: ...188 Chapter 21 Controlling gdb ...
Page 204: ...194 Chapter 22 Canned Sequences of Commands ...
Page 206: ...196 Chapter 23 Command Interpreters ...
Page 216: ...206 Chapter 25 Using gdb under gnu Emacs ...
Page 296: ...286 Chapter 27 gdb Annotations ...
Page 300: ...290 Chapter 28 Reporting Bugs in gdb ...
Page 322: ...312 Chapter 30 Using History Interactively ...
Page 362: ...352 Appendix D gdb Remote Serial Protocol ...
Page 380: ...370 Appendix F GNU GENERAL PUBLIC LICENSE ...
Page 386: ...376 Appendix G GNU Free Documentation License ...
Page 410: ......