Red Hat ENTERPRISE LINUX 3 - DEBUGGING WITH GDB Manual page 177

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 . To do this, define in the VxWorks
rdb.a INCLUDE_RDB
configuration file and rebuild your VxWorks kernel. The resulting kernel contains
configAll.h
, and spawns the source debugging task when VxWorks is booted. For more infor-
rdb.a tRdbTask
mation on configuring and remaking VxWorks, see the manufacturer's manual.
Once you have included in your VxWorks system image and set your Unix execution search
rdb.a
path to find gdb, you are ready to run gdb. From your Unix host, run (or , depending on
gdb vxgdb
your installation).
gdb comes up showing the prompt:
(vxgdb)
20.2.1.1. Connecting to VxWorks
The gdb command lets you connect to a VxWorks target on the network. To connect to a
target
target whose host name is " ", type:
tt
(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 , and
path
execute the command again.
target
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 command to download a file from Unix to VxWorks incrementally.
load
The object file given as an argument to the command is actually opened twice: first by the
load
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 may
prog.o
reside in in VxWorks and in on the host. To load
/vw/demo/rdb /vw/demo/rdb
vxpath hostpath
this program, type this on VxWorks: