The following sections describe how to use the VxSim compilers. The recommended way to build VxSim modules is to use the project tool. For complete information on this tool, see the Tornado User's Guide: Projects. If you are using manual methods in your project, the information required for manual builds and loading is summarized below.

This information applies to using manual methods on both the built-in version of VxSim and the optional networking product.

Setting the preprocessor variable CPU ensures that VxWorks and your applications build with the appropriate features enabled. Define this variable to one of the following values, to match the host you are using:   

SIMSPARCSOLARIS	VxSim for Solaris
SIMHPPA	VxSim for HP-UX
SIMNT	VxSim for Windows NT

All VxWorks simulators use the GNU C/C++ compiler.

	CAUTION: The compiler used by the Tornado tools to compile VxSim applications for Windows is the GNU C/C++ compiler rather than the MicroSoft tools.

Solaris

The following is an example of a compiler command line for VxSim development. The file to be compiled in this example has a base name of applic.

% ccsimso -DCPU=SIMSPARCSOLARIS -ansi -nostdinc -g -fno-builtin \ 
-fvolatile -DRW_MULTI_THREAD -D_REENTRANT -O2 -I. \ 
-I /wind/target/h -c applic.c

HP-UX

The following is an example of a compiler command line for VxSim development. The file to be compiled in this example has a base name of applic.

% cchppa -g -ansi -nostdinc -DRW_MULTI_THREAD -D_REENTRANT -O2 \ 
-fvolitile -fno-builtin -I. -I/wind/target/h -DCUP_SIMHPPA \ 
-c applic.c

Windows

The following is an example of a compiler command line for VxSim development. The file to be compiled in this example has a base name of applic.

% ccsimpc -DCPU=SIMNT -mpentium -ansi -nostdinc -g -nostdlib \ 
-fno-builtin -fno-defer-pop -Wall -DRW_MULTI_THREAD \ 
-D_REENTRANT -I. -I C:/Tornado/target/h -c applic.c 

Option Definitions

The options shown in the example have the following meanings:¹

ccsimso

Required; use ccsimso for the Solaris simulator, cchppa for the HP-UX simulator, and ccsimpc for the Windows simulator.

-DCPU=SIMNT

Required; defines the CPU type. See the table on page Defining the CPU Type.

-mpentium

Optional for Windows only; specifies Pentium optimizations.

-ansi

Recommended; supports all ANSI standard C programs.

-nostdinc

Required; searches only the directories specified with the -I flag (see below) and the current directory for header files. Does not search host-system include files.

-O2

Optional; implements optimization. Not recommended for the PC simulator.

-g

Optional; produces debugging information.

-nostdlib

Required for Windows; does not use the standard system startup files or libraries when linking.

-fvolatile

Required for Solaris and HP-UX; considers all memory references through pointers to be volatile.

-fno-builtin

Required; uses library calls even for common library subroutines.

-fno-defer-pop

Required for Windows, optional for UNIX. Causes arguments to each function call to be popped as soon as the function returns.

-Wall

Optional; enables most warnings.

-DRW_MULTI_THREAD

Required; specifies Rogue Wave multi-threading.

-D_REENTRANT

Required; causes reentrant code to be generated.

-I $WIND_BASE/target/h

Required; includes VxWorks header files. (Additional -I flags may be included to specify other header files.)

-c

Required; specifies that the module is to be compiled only, and not linked for execution under the host.

applic.language_id

Required; the files to compile. For C compilation, specify a suffix of .c. For C++ compilation, specify a suffix of .cpp. The output is an unlinked object module with the suffix .o; for the example, the output is applic.o. The object module format for each simulator is as follows:

SIMSPARCSOLARIS	ELF
SIMHPPA	SOM
SIMNT	a.out

Following C++ compilation, the compiled object module (applic.o) is munched. Munching is the process of scanning an object module for non-local static objects, and generating data structures that VxWorks run-time support can use to call the object constructors and destructors. See 5.2.5 Munching C++ Application Modules.

By default, applications can be loaded into VxSim while it is running. Alternatively, the application can be statically linked to VxSim by modifying the target makefile.

	CAUTION: VxSim for HP-UX uses the HP native linker ld rather than the GNU linker (ldhppa).

This information applies to using manual methods on both the built-in version of VxSim and the optional networking product.

Dynamic Loading

To load your application dynamically into VxSim, follow these steps:

1. Start VxSim as described in Starting VxSim.

1. From a WindSh window, use the ld( ) function to load the application dynamically. For example:

-> ld </usr/tony/application.o 
value = 3957696 = 0x3c63c0

A nonzero return value indicates that the load was successful.

As with VxWorks, the Tornado dynamic linker ld( ) requires a relocatable object module. The object format is as follows:

Table H-1:  Object Formats by VxSim Host

Host Type	Object Format	Produced By
Solaris 2	elf	ccsimso
HP-UX	som	cchppa
Windows	a.out	ccsimpc

Static Linking

The other method of linking is to modify the target makefile to link the application code statically into VxSim when VxSim is built. This method is also useful if you have already debugged a module and you do not want to download it to the target every time you start VxSim.

To link the application code statically into VxSim, follow these steps:

1. Add your application modules in the makefile definition of MACH_EXTRA. The makefile is ${WIND_BASE}/target/config/bspname/Makefile, where bspname is one of solaris, hpux, or simpc:

MACH_EXTRA = application.o

If your application module is in another directory, specify the pathname.

1. Use make to rebuild VxSim with application.o linked in.

For a discussion of using BSP makefiles to incorporate application modules, see 8. Configuration and Build.

Partial Linking

Large applications may be managed more effectively by using multiple object files. Before downloading the application to VxSim, the objects can be combined into a single file by performing a partial link as shown below:

% /bin/ldsimso -B immediate -N -r -o application.o module1.o \ 
module2.o ...

 
% /bin/ld -B immediate -N -r -o application.o module1.o module2.o ...

 
% /bin/ldsimpc -B immediate -N -r -o application.o module1.o \ 
module2.o ...

If you want to use CrossWind to debug your application on the HP-UX simulator, you must run xlinkHppa on the partially-linked object file before downloading it to VxWorks. For example:

% xlinkHppa application.o

For more information on xlinkHppa, see its reference entry.

The following tools are available to extract the symbol table from an object file created for a simulator. The syntax is:

elfXsyms

is used for an ELF file for the Solaris simulator. The syntax is:

elfXsyms < objMod > symTbl 

xsymHppa

is used for a SOM file for the HP-UX simulator. The syntax is:

xsymHppa < objMod > symTbl 

No tool is required for the Windows simulator. When a symbol table is required, the loader loads the entire executable but only the symbol table is referenced.

1:  For more information on these and other compiler options, see the GNU ToolKit User's Guide. WRS supports compiler options used in building WRS software; see the Guide for a list. Other options are not supported, although they are available with the tools as shipped.