This section describes configurations involving the debugging of
embedded operating systems that are available for several different
architectures.
gdb includes the ability to debug programs running on
various real-time operating systems.
20.2.1. 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:
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:
-> cd "vxpath/vw/demo/rdb" |
Then, in gdb, type:
(vxgdb) cd hostpath/vw/demo/rdb
(vxgdb) load prog.o |
gdb displays a response similar to this:
Reading symbol data from wherever/vw/demo/rdb/prog.o... done. |
You can also use the load command to reload an object module
after editing and recompiling the corresponding source file. Note that
this makes gdb delete all currently-defined breakpoints,
auto-displays, and convenience variables, and to clear the value
history. (This is necessary in order to preserve the integrity of
debugger's data structures that reference the target system's symbol
table.)
20.2.1.3. Running tasks
You can also attach to an existing task using the attach command as
follows:
where task is the VxWorks hexadecimal task ID. The task can be running
or suspended when you attach to it. Running tasks are suspended at
the time of attachment.
