Node:VxWorks, Up:Embedded OS

#### Using GDB with VxWorks

`target vxworks` machinename``
  A VxWorks system, attached via TCP/IP. The argument machinename is the target system's machine name or IP address.

On VxWorks, `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.)

`VxWorks-timeout` args``
  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 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)