C ++ development under Tornado

5.2 C ++ development under Tornado
The basic C ++ support is bundled in the tornado development environment. VxWorks provides header files containing c ++ security statements for all programs and required run-time support. standard tornado interactive development tools such as debuggers, shells, and new loaders all support C ++.

5.2.1 tool support
Windsh
Tornado supports C and C ++ development languages. windsh can explain simple C ++ expressions. To practice the C ++ function that is missing in the C-expression interpreter (c-expression interpreter), you can compile and download programs encapsulated by special C ++ syntax. See tornado User's Guide: tornado tools reference or windsh C ++ online reference.
Demangling
When a C ++ function is compiled, the number of class members (if any) and the type and number of function parameters are encapsulated in the linkage name of the function. This becomes name mangling or mangling. The debugging and system information in windsh can print the C ++ function name in the form of demangled or mangled.
The default display is GNU. In addition, arm and none (no demangling) are optional. To select another mode, change the Tcl variable shdemanglestyle.
Example:
->? Set shdemanglestyle none
The name of the overloaded function.
When you call an overload function, windsh prints the symbol of the matched function and prompts you to enter the desired function. For more information about how windsh handles the names of overloaded functions, including examples, see tornado User's Guide: shell.
Debugger
The tornado debugger can debug C ++ member functions, including one-step debugging in constructor and template. For details, see tornado user's sguide: tornado tools reference and debugging with GDB.
5.2.2 Programming Problems (programming issues)
Make the C ++ entry available in C code
If you want to reference a (non-overloaded, global) C ++ object (symbols) from the C code ), you must use extern "C" for prototype description so that the C Connection Program knows it:
# Ifdef _ cplusplus
Extern "C" Void myentrypoint ();
# Else
Void myentrypoint ();
# Endif
You can also use this syntax to call the C object (symbols) in C ++ code ). The C object in VxWorks can be called in C ++, because the VxWorks header file declares that this mechanism is used.
5.2.3 compile C ++ applications
Tornado project tool fully supports C ++. We recommend that you use the project tool to configure and compile C ++ programs. The following information is useful for understanding the C ++ environment. Unless artificial methods are used for special reasons, the methods described in tornado User's Guide: projects should be used.
For more information about the GNU Compiler and related tools, see the GNU toolkit user's guide.
When the GNU Compiler is used to compile the C ++ module. CPP ). compiling a C ++ program in the VxWorks environment includes the following steps:
1. Each C ++ source code file is compiled into the target code, just like a C program. For example, compile a 68k target:
Cc68k-fno-builtin-I $ wind_base/target/h-nostdinc-O2/
-Dcpu = mc68040-C Foo. cpp
Cc68k-fno-builtin-I $ wind_base/target/h-nostdinc-O2/
-Dcpu = mc68040-C bar. cpp
2. The target code is munch (see munching C ++ application modules). In our example:
Nm68k Foo. O Bar. o | wtxtcl $ wind_base/host/src/hutils/Munch. Tcl/
-ASM 68 K> ctdt. c
Cc68k-C ctdt. c
3. The target code is connected to the compiled munch output. (For downloadable applications, they can be connected together using partially-R. For applications that can be started, they can be statically connected with the VxWorks BSP .) If you use the GNU tool, you can call the connector from the compiler driver as follows:
Cc68k-r ctdt. O Foo. O Bar. O-o linkedobjs. o
Connect the two target modules Foo. O and bar. O to generate the downloadable target code linkedobjs. O. If you use option-frepo, use ccarch instead of ldarch to instantiate the template. (See 5.2.7 template instantiation)
Note: If you use Wind River system makefile to construct an application, munching is executed through make.
Caution: In the connection step,-R is used to create a local connection. A local connection file can still be relocated. It is also suitable for using the VxWorks module loader to download and connect. The option-ur described in GNU toolkit User's Guide: Using LD is used to parse the C ++ constructor involved. This option is used for native development instead of cross-development. VxWorks's c ++ module does not use option-Ur.
5.2.4 configuration constant
Generally, the VxWorks kernel includes C ++ run-time, basic iostream, and STL support. The following macro is included to add/delete C ++:
Include_cplus
Including all the basic C ++ run-time support. This allows you to download and run the compiled munched C ++ module. This does not configure any wind-based class library to enter VxWorks.

Include_cplus_stl
Including STL support.

Include_cplus_string
Includes the basic components of the string library.

Include_cplus_iostreams
Including the basic components of the iostream library.

Include_cplus_complex
Contains the basic components of a complex library.

Include_cplus_iostreams_full
Including the full iostream Library; this means that include_cplus_iostreams is also defined.

Include_cplus_string_io
Including the input/output functions of strings. This means that include_cplus_string and include_cplus_iostreams are also defined.

Include_cplus_complex_io
Including the input/output of the complex object. This means that include_cplus_iostreams and include_cplus_complex are also defined.
To include one or more wind base classes, including one or more constants as follows:
Include_cplus_vxw
Includes the VxWorks Wrapper class library.

Include_cplus_tools
Includes tools. h ++ class library of rogue wave.
For more information about configuring VxWorks, see tornado User's Guide: projects.
5.2.5 munching C ++ application module
Modules written in C ++ must undergo additional host process steps before downloading them to the VxWorks target machine. This additional step (called munching) initializes the static object and ensures that when the module is downloaded to VxWorks, c ++'s run-time support can call correct constructor and destructor for all static objects in the appropriate order.
Run the following command to compile hello. cpp and then munch hello. O. The result is displayed in the hello. Out file of Munch. It can be loaded through the tornado module Loader:
Cc68k-iinstalldir/target/h-dcpu = mc68020-nostdinc-fno-builtin/
-C hello. cpp
Nm68k hello. o | wtxtcl installdir/host/src/hutils/Munch. Tcl/
-ASM 68 K> ctdt. c
Cc68k-C ctdt. c
Ld68k-R-O hello. out hello. O ctdt. o
Note: You can replace installdir with the actual path name, $ wind_base (UNIX), or % wind_base % (Windows.
Note: The GNU toolkit User's Guide: Using LD describes option-ur to parse the C ++ constructor involved. this option is used for native development instead of cross-development ). the C ++ module of VxWorks does not use option-Ur.
5.2.6 static constructor and destructor
After munching, downloading, and connecting, you must call static constructor and destructor.

Method for calling static constructor and destructor
VxWorks provides two methods to call static constructor and destructor: [these two methods are complementary (interactively)]
Automatic: Call the static constructor is considered to be the downloaded side effect; call the static destructor is considered to be the unmounted side effect.
Manual: Call cplusctors () and cplusdtors () to call static constructor and destructor.
Call cplusxtorset () to change the method. view its details in the windsh reference entry. Call cplusstratshow () to display the current method.
In the automatic method, it is the default, and the static constructor is called immediately after the download is successful. If the method is set to automatic before the module is downloaded, the static constructor of the module is called before the module loader returns to its caller. In the automatic method, the module uninstaller calls the static destructor of the module before the module is actually detached.
Manually calling static constructors is the result of calling cplusctors (). For windsh reference, you can find more details about the functions cplusctors () and cplusdtors. To call the currently loaded static constructor and destructor, parameters are not included in manual mode. The manual mode can also call static constructor and destructor one by one on the module.
Constructor and destructor at system start and end
When you create a launched VxWorks application, you call the static constructor during system initialization. Change the usrroot () function in usrconfig. C to include calls to cplusctorslink (). This calls all static constructors connected to the system.
To modify usrconfig. C to call cplusctorslink (), find the C ++ initialization part:
# Ifdef include_cplus/* C ++ product */
Cpluslibinit ();
# Endif

# Ifdef include_cplus_min/* C ++ product */
Cpluslibmininit ();
# Endif
Next, add cplusctorslink () to one or two parts, depending on the system requirements. In the following example, cplusctorslink () is called only when the minimum C ++ is configured ():
# Ifdef include_cplus_min/* C ++ product */
Cpluslibmininit ();
Cplusctorslink ();
# Endif
Note: static objects are not initialized unless cplusctorslink () is called. Therefore, if the application uses static objects in usrroot (), call cplusctorslink () before using them ().
To make cplusctorslink () run correctly, the munch operation must be performed on the fully connected VxWorks image rather than on a single module.
The corresponding function cplusdtorslink () is used to call all static destructor. This function is useful in systems that require process uninstallation in sequence.
In the code, the call to cplusdtorslink () is included where all static destructor are suitable for calling. These static destructor are initially connected to the system.
Functions cplusctorslink () and cplusdtorslink () do not call the static constructor and destructor of the downloaded module after system initialization. If the system uses the module downloader, the following process is described in <Method for invoking static constructor and destructor>.
5.2.7 template instantiation
The C ++ toolchain supports three different template instantiation methods. The simplest (this is also the default method used in VxWorks makefiles) is implicit instantiation (imlicit instantiation ). in this way, the code of each template is expanded in each module that requires it. To make the template work, the implementation part of the template must be visible in each module that uses it. This is usually done by adding the template feature in the header file and their
Declaration. The disadvantage of implicit instantiation is that it will cause code replication and the application is too large.
The second method is to use the syntax in Example 5-1 to display any template required for instantiation. In this method, the option-fno-implicit-templates should be used during compilation. This design allows you to have maximum control over where to instantiate the template and avoid code expansion.
-Frepo
The manual template instantiation method combines the simplicity of implicit instantiation with the smaller coverage (footprint) obtained. You can operate on the template instance database of each module.
The compiler will generate files with the. RPO extension. These files list all template instances, which can be used in the target files that can be instantiated. The compiler connects to wrapper collect2 and then updates the. RPO file to tell the compiler where to place these instances and reconstructs any affected target files. When the compiler continues to place instances in the same file, the connection overhead (Link-time overhead) can be ignored during the first pass.
Procedure)
The template header file must contain the template implementation section. Generally, if the template implementation is saved in the. cpp file, # include thetemplate. cpp must be added to the template header file.
The. RPO file must be created for the complete construction with option = frepo, which tells the Compiler which template is instantiated. The connection steps should be started by ccarch instead of ldarch.
Then the module is compiled as usual (but the option-frepo does not have other template parameters ).
When a new template instance is available, the related part of the project must be rebuilt to update the. RPO file.
Loading Sequence
The dynamic connection capability of Tornado requires the module to include the definition of the downloaded object before referencing the downloaded object (Symbol. For example, in the following example, you should download paira. O before downloading pairb. O. (You should also connect them in advance and download the connected targets)
Example
This example uses the standard VxWorks BSP makefile (assuming a 68k target for specific purposes ).
Example 5-1: Sample makefile
Make paira. O pairb. O added_c ++ flags =-frepo

/* Dummy link step to instantiate templates */
Cc68k-r-o pair paira. O pairb. o

/* In this case the template pair <int>: sum (void)
* Will be instantiated in paira. O.
*/

// Pair. h

Template <class T> class pair
{
Public:
Pair (T _ x, t _ y );
T Sum ();

Protected:
T x, y;
};

Template <class T>
Pair <t>: Air (T _ x, t _ y): X (_ x), y (_ y)
{
}

Template <class T>
T pair <t>: sum ()
{
Return X + Y;
}

// Paira. cpp
# Include "pair. H"

Int add (int x, int y)
{
Pair <int> two (x, y );
Return two. sum ();
}

// Pairb. cpp
# Include "pair. H"

Int double (int x)
{
Pair <int> two (x, x );
Return two. sum ();
}