Target Shell 符号表加载方法

 Todule Unloader

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):

• INCLUDE_SYM_TBL for target symbol table support, plus one of the following:

• INCLUDE_NET_SYM_TBL to load the symbol table from the network (vxWorks.sym; you will also need to separately loadvxWorks)

• INCLUDE_STANDALONE_SYM_TBL to build a VxWorks image that includes the target symbol table (vxWorks.st)

• INCLUDE_LOADER

• INCLUDE_UNLOADER

If the target symbol table is included, usrRoot( ) runs hashLibInit( ) andsymLibInit( )to initialize the corresponding libraries. The target symbol table is created by callingsymTblCreate( ). For convenience during debugging (see9.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 calledvxWorks.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 callingloadSymTbl( ) (whose source is ininstallDir/target/src/config/usrLoadSym.c). This routine uses the target-resident module loader to load symbols fromvxWorks.sym into the target symbol table.

For the most part, the target-resident facilities work the same as their Tornado host counterparts; see8.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 theloadLib, unldLib, andsymLib reference entries.