To make full use of the target shell's features, you should also define the target symbol table, as well as the target module loader and unloader. Select the following components (identified by their associated macros) in the VxWorks view (see Tornado User's Guide: Projects for configuration information):

If the target symbol table is included, usrRoot( ) runs hashLibInit( ) and symLibInit( )to initialize the corresponding libraries. The target symbol table is created by calling symTblCreate( ). For convenience during debugging (see 9.2.3 Debugging with the Target Shell), it is most useful to have access to all symbols in the system. On the other hand, a production version of a system can be built that does not require the target symbol table, if (for example) memory resources are constrained.

The symTblCreate( ) call creates an empty target symbol table. VxWorks system facilities are not accessible through the target shell until the symbol definitions for the booted VxWorks system are entered into the target symbol table. This is done by reading the target symbol table from a file called vxWorks.sym in the same directory from which vxWorks was loaded (installDir/target/config/bspname). This file contains an object module that consists only of a target symbol table section containing the symbol definitions for all the variables and routines in the booted system module. It has zero-length (empty) code, data, and relocation sections. Nonetheless, it is a legitimate object module in the standard object module format.

The symbols in vxWorks.sym are entered in the target symbol table by calling loadSymTbl( ) (whose source is in installDir/target/src/config/usrLoadSym.c). This routine uses the target-resident module loader to load symbols from vxWorks.sym into the target symbol table.

For the most part, the target-resident facilities work the same as their Tornado host counterparts; see 8.9.1 Creating a Standalone VxWorks System with a Built-in Symbol Table, 8.4.4 Downloading an Application Module, and 8.4.6 Unloading Modules. However, as stated earlier, the target-resident facilities can be useful if you are building dynamically configured applications. For example, with the target-resident loader, you can load from a target disk as well as over the network, with these caveats: If you use the target-resident loader to load a module over the network (as opposed to loading from a target-system disk), the amount of memory required to load an object module depends on what kind of access is available to the remote file system over the network. Loading a file that is mounted over the default network driver requires enough memory to hold two copies of the file simultaneously. First, the entire file is copied to a buffer in local memory when opened; second, the file resides in memory when it is linked to VxWorks. On the other hand, loading an object module from a host file system mounted through NFS only requires enough memory for one copy of the file (plus a small amount of overhead). In any case, however, using the target-resident loader takes away additional memory from your application--most significantly for the target-resident symbol table required by the target-resident loader.

For information on the target-resident module loader, unloader, and symbol table, see the loadLib, unldLib, and symLib reference entries.

VxWorks includes system information routines which print pertinent system status on the specified object or service; however, they show only a snapshot of the system service at the time of the call and may not reflect the current state of the system. To use these routines, you must define the associated configuration macro (see the Tornado User's Guide: Projects). When you invoke them, their output is sent to the standard output device. Table 9-2 lists common system show routines.

Table 9-2:  Show Routines 

An alternative method of viewing system information is the Tornado browser, which can be configured to update system information periodically. For information on this tool, see the Tornado User's Guide: Browser.

VxWorks also includes several network information routines. These routines are initialized by defining INCLUDE_NET_SHOW in your VxWorks configuration; see 8. Configuration and Build. Table 9-3 lists commonly called network show routines.

Table 9-3:  Network Show Routines