Tornado

5
Shell
check to be sure the LD_SEND_MODULES variable of shConfig is set to “on” or use
the LD_PATH facility to tell the target server about the path known to the shell.
Example 5-3
Loading a Module: Alternate Path Names
Your target server is running on a UNIX host. You start a WindSh on a Windows
host with LD_SEND_MODULES set to “off” (changed from the default). You want
to download a file that resides on the Windows host called c:/tmp/test.o.
5
-> ld < c:/tmp/test.o
Loading c:/tmp/test.o
WTX Error 0x2 (no such file or directory)
value = -1 = 0xffffffff
This behavior is normal because the UNIX target server does not have access to this
path. To correct the problem, reset LD_SEND_MODULES to “on” (the default).
-> ?shConfig LD_SEND_MODULES on
-> ld < c:/tmp/test.o
Loading C:/tmp/test.o
value = 17427840 = 0x109ed80
For more information on using LD_SEND_MODULES, LD_PATH, and other
shConfig facilities, see WindSh Environment Variables, p.155.
Certain WindSh commands and browser utilities imply dynamic downloads of
auxiliary target-resident code. These subroutines fail in situations where the shell
and target-server view of the file system is incompatible. To get around this
problem, download the required routines explicitly from the host where the target
server is running (or configure the routines statically into the VxWorks image).
Once the supporting routines are on the target, any host can use the corresponding
shell and browser utilities. Table 5-16 lists the affected utilities. The object modules
are in wind/target/lib/objcputypegnuvx.
Table 5-16
Shell and Browser Utilities with Target-Resident Components
Utility
repeat( )
period( )
tt( )
Browser spy panel
Supporting Module
repeatHost.o
periodHost.o
trcLib.o,
ttHostLib.o
spyLib.o
197