Tornado provides access to the loader by several routes:

The Tornado shell provides an interpretive environment that offers easy access to the loader. From the shell, access the loader through the ld( ) command:

-> ld symbolsVisibility, commonSymbolsPolicy, "objectFile"

The symbolsVisibility argument may be:

Load no symbols to the target server symbol table (mutually exclusive with other options). There is no way to know the contents of the module.

Load only global symbols to the target server symbol table. This is the default.

Load both local and global symbols to the target server symbol table.

The commonSymbolsPolicy argument may be:

Keep common symbols isolated, visible from the object module only. This option prevents any matching with already-existing symbols (in other words, the relocations that refer to these symbols are kept local). Common symbols are added to the symbol table unless LOAD_NO_SYMBOLS is set. This is the default option with behavior equivalent to LOAD_COMMON_MATCH_NONE. (For definitions of these and other options, see 3.5.4 Loader Options.)

Seek a matching symbol in the target server symbol table, considering only symbols in user modules. If no matching symbol exists, the behavior is equivalent to LOAD_COMMON_MATCH_NONE.

Seek a matching symbol in the target server symbol table, considering all symbols. If no matching symbol exists, the behavior is equivalent to LOAD_COMMON_MATCH_NONE.

For a complete discussion of loader behavior, see 3.5 Loader Architecture.

To call the loader from the shell, enter:

-> ld 0, 0, "/home/users/me/myFile.o"

You can also use input redirection:

-> ld </home/users/me/myFile.o

Another way to access the loader facilities of the target server is through the WTX Tcl binding to the WTX protocol. This environment offers the scripting advantages of Tcl and the ability to manipulate the WTX protocol directly. From the wtxtcl tool (see 4.4.2 Starting a wtxtcl Session), access the loader through the wtxObjModuleLoad routine:

wtxtcl> wtxObjModuleLoad [option] object- file

The option argument is an optional parameter from the following list:

LOAD_NO_SYMBOLS		LOAD_COMMON_MATCH_NONE
LOAD_LOCAL_SYMBOLS		LOAD_COMMON_MATCH_USER
LOAD_GLOBAL_SYMBOLS		LOAD_COMMON_MATCH_ALL
LOAD_ALL_SYMBOLS		LOAD_HIDDEN_MODULE
LOAD_FULLY_LINKED		LOAD_BAL_OPTIM
LOAD_NO_DOWNLOAD		LOAD_FILE_OUTPUT
LOAD_CORE_FILE

You can combine several options by linking them with the "|" character. For a detailed discussion of these parameters, see 3.5.4 Loader Options.

Examples:

wtxtcl> wtxObjModuleLoad /home/users/me/myFile.o 
wtxtcl> wtxObjModuleLoad LOAD_ALL_SYMBOLS /home/users/me/myFile.o 
wtxtcl> wtxObjModuleLoad LOAD_GLOBAL_SYMBOLS|LOAD_COMMON_MATCH_USER \ 
    /home/users/me/myFile.o

You can also call the loader from C programs on the host, using the WTX C language binding. For details about using wtxObjModuleLoad( ), see the online reference material under Tornado API Reference>WTX C Library. For general information on using C, see 4.5 WTX C API.

The target-server loader implementation allows you to submit load operations asynchronously. Three APIs provide routines that support the loader: the Tcl, C and Java APIs. Each API provides three routines to handle this feature. The routines are listed below according to the Tcl convention:

Submit a load operation. This routine returns when the file has been written to the target server memory.

Cancel a submitted load.

Get information about the status of a submitted load. The returned information can be one of the following:

LOAD_PENDING

The load is in queue.

LOAD_INITIALIZED

The being processed.

LOAD_RELOCATING

The loader is relocating symbols.

LOAD_DOWNLOADING

The loader is downloading the segments on the target.

LOAD_COMPLETE

The load has been done.

LOAD_ABORTED

The load has been cancelled.