Up: Embedded OS
21.2.1 Using gdb with VxWorks
- A VxWorks system, attached via TCP/IP. The argument machinename is the target system's machine name or IP address.
load links filename dynamically on the
current target system as well as adding its symbols in gdb.
gdb enables developers to spawn and debug tasks running on networked
VxWorks targets from a Unix host. Already-running tasks spawned from
the VxWorks shell can also be debugged. gdb uses code that runs on
both the Unix host and on the VxWorks target. The program
gdb is installed and executed on the Unix host. (It may be
installed with the name
vxgdb, to distinguish it from a
gdb for debugging programs on the host itself.)
- All VxWorks-based targets now support the option
vxworks-timeout. This option is set by the user, and args represents the number of seconds gdb waits for responses to rpc's. You might use this if your VxWorks target is a slow software simulator or is on the far side of a thin network line.
The following information on connecting to VxWorks was current when this manual was produced; newer releases of VxWorks may use revised procedures.
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
information on configuring and remaking VxWorks, see the manufacturer's
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
vxgdb, depending on your installation).
gdb comes up showing the prompt: