c-config4.html

this about vxworks operations systems

<dd><div class="Indent2"><a name="85385"> </a>Required; allows the scope of variables declared within a for loop to be outside of the for loop.</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85386"> </a><b class="command">-G 0 </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85388"> </a><b class="command"></b>Do not use the MIPS global pointer (<b class="command">ccmips</b> only).</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85389"> </a><b class="command">-I&nbsp;&nbsp; </b><b class="symbol_UC">$(WIND_BASE)</b><b class="command">/target/h </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85394"> </a>Include VxWorks header files (see <a href="c-config4.html#85044"><i class="title">8.4.1&nbsp;Using VxWorks Header Files</i></a>).</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85395"> </a><b class="command">-m68040 </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85397"> </a><b class="command"></b>Generate code for a specific variant of the MC680<i class="textVariable">x</i>0 family.</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85398"> </a><b class="command">-mcpu= </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85400"> </a><b class="command"></b>Generate MIPS R4200 or R4600 specific code (<b class="command">ccmips</b> only).</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85401"> </a><b class="command">-mips3 </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85403"> </a><b class="command"></b>Issue instructions from level 3 of the MIPS instruction set (<b class="command">ccmips</b> only).</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85404"> </a><b class="command">-mno-486 </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85406"> </a><b class="command"></b>Generate code optimized for an i386 rather than for an i486 (<b class="command">cc386</b> only).</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85407"> </a><b class="command">-msparclite </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85409"> </a><b class="command"></b>Generate SPARClite-specific code (<b class="command">ccsparc</b> only).</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85410"> </a><b class="command">-nostdinc </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85412"> </a><b class="command"></b>Do not search host-system header files; search only the directories specified with the <b class="command">-I</b> flag and the current directory for header files.</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85413"> </a><b class="command">-O </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85415"> </a><b class="command"></b>Perform standard optimizations.</div>
<br>
</dl>

</dl>

<dd><div class="Item"><a name="85416"> </a><b class="command">-O2 </b></div>
<dl class="margin">

<dl class="margin">

<dd><div class="Indent2"><a name="85419"> </a><b class="command"></b>Use level 2 optimization.<b></b></div>
<br>
</dl>

</dl>

</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="85421">Compiling C++ Modules</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="85424"> </a>Tornado supports the GNU compiler, a standard part of the cross-compilation tools distributed for Tornado, compiles source programs in either C or C++. To use this compiler for C++, invoke <b class="command">cc</b><i class="textVariable">arch</i> on any source file with a C++ suffix (such as <b class="file">.cpp</b>). For complete information on using C++, including a detailed discussion of compiling C++ modules, see <a href="c-wfc.html#84368"><i class="title">5.&nbsp;C++ Development</i></a>. </p>
<dd><p class="Body"><a name="85462"> </a>Compiling C++ applications in the VxWorks environment involves the following steps:</p>
</dl>

<dl class="margin">

<p><ol class="List"><li value="1."><a name="85463"> </a>C++ source code is compiled into object code for a specific target architecture, just as for C applications.</li></ol></p>
<p><ol class="List"><li value="2."><a name="85465"> </a>The compiled object module is <i class="term">munched</i>. 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 objects' constructors and destructors. The details are described in <a href="c-wfc2.html#84479"><i class="title">5.2.5&nbsp;Munching C++ Application Modules</i></a>.</li></ol></p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="85471">8.4.3  &nbsp;&nbsp;Static Linking (Optional)</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="85473"> </a><b></b>After you compile an application module, you can load it directly into the target with the Tornado dynamic loader (through the shell or through the debugger). </p>
<dd><p class="Body"><a name="85474"> </a>In general, application modules do not need to be linked with the linker from the GNU ToolKit, <b class="command">ld</b><i class="textVariable">arch</i>. However, using <b class="command">ld</b><i class="textVariable">arch</i> may be required when several application modules cross-reference each other. The following example is a command to link several application modules, using the GNU linker for the MC680<i class="textVariable">x</i>0 family of processors.</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="85476"></b><tt class="output">C:\devt&gt; </tt><b>ld68k -o applic.o -r applic1.o applic2.o applic3.o</a></b></pre>
</dl>

<dd><p class="Body"><a name="85477"> </a>This creates the object module <b class="file">applic.o</b> from the object modules <b class="file">applic1.o</b>, <b class="file">applic2.o</b>, and <b class="file">applic3.o</b>. The <b class="command">-r</b> option is required, because the object-module output must be left in relocatable form so that it can be downloaded and linked to the target VxWorks image.</p>
<dd><p class="Body"><a name="85479"> </a>Any VxWorks facilities called by the application modules are reported by <b class="command">ld</b><i class="textVariable">arch</i> as unresolved externals. These are resolved by the Tornado loader when the module is loaded into VxWorks memory.</p>
</dl>

</dl>

<dl class="margin">
<dd>
<p class="table" callout>
<table border="0" cellpadding="0" cellspacing="0">
<tr valign="top">
<td valign="top" width="40">
<br>
<img border="0" alt="*" src="icons/warning.gif">
</td>

<td>
<hr><div class="CalloutCell"><a name="85484"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">WARNING:  </font></b></a>Do not link each application module with the VxWorks libraries. Doing this defeats the load-time linking feature of Tornado, and wastes space by writing multiple copies of VxWorks system modules on the target.</div>
</td>


</tr>
<tr valign="top">
<td></td>

<td><hr></td>


</tr>

<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p callout>



</dl>
<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="85491">8.4.4  &nbsp;&nbsp;Downloading an Application Module</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="85493"> </a>After application object modules are compiled (and possibly linked by the host <b class="command">ld</b><i class="textVariable">arch</i> command), they can be dynamically loaded into a running VxWorks system by invoking the Tornado module loader. You can do this either from the Tornado shell using the built-in command <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b>, or from the debugger using the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Debug</font></b> menu or the <b class="command">load</b> command.</p>
<dd><p class="Body"><a name="85494"> </a>The following is a typical load command from the Tornado shell:</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="85495"></b><tt class="output">-&gt;</tt><b> ld &lt;applic.o</a></b></pre>
</dl>

<dd><p class="Body"><a name="85496"> </a>This relocates the code from the host file <b class="file">applic.o</b>, linking to previously loaded modules, and loads the object module into the target's memory. Once an application module is loaded into target memory, any subroutine in the module can be invoked directly from the shell, spawned as a task, connected to an interrupt, and so on.</p>
<dd><p class="Body"><a name="85497"> </a>The shell <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b> command, by default, adds only global symbols to the symbol table. During debugging, you may want local symbols as well. To get all symbols loaded (including local symbols), you can use the GDB command <b class="command">load</b> from the debugger. Because this command is meant for debugging, it always loads all symbols. Alternately, you can load all symbols by calling the shell command <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b> with a full argument list instead of the shell-redirection syntax shown above. When you use an argument list, you can get all symbols loaded by specifying a 1 as the first argument, as in the following example:</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="85498"></b><tt class="output">-&gt;</tt><b> ld 1,0,"applic.o"</a></b></pre>
</dl>

<dd><p class="Body"><a name="85499"> </a>In the foregoing examples, the object module <b class="file">applic.o</b> comes from the shell's current working directory. Normally, you can use either relative path names or absolute path names to identify object modules to <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b>. If you use a relative path name, the shell converts it to an absolute path (using its current working directory) before passing the download request to the target server. In order to avoid trouble when the shell where you call <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b> is not running on the same host as its target server, Tornado supplies the <b class="symbol_UC">LD_SEND_MODULES</b> facility; see the<i class="title"> Tornado User's Guide: Shell</i>. If you are using a remote target server and <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b> fails with a "no such file" message, be sure that <b class="symbol_UC">LD_SEND_MODULES </b>is set to "on."</p>
</dl>

</dl>

<dl class="margin">
<dd>
<p class="table" callout>
<table border="0" cellpadding="0" cellspacing="0">
<tr valign="top">
<td valign="top" width="40">
<br>
<img border="0" alt="*" src="icons/caution.gif">

</td>

<td>
<hr><div class="CalloutCell"><a name="85504"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">CAUTION:  </font></b></a>(Windows) If you call <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b> with an explicit argument list, any backslash characters in the module-name argument must be doubled. If you supply the module name with the redirection symbol, as in the earlier example in this section, no double backslashes are needed. See the<i class="title"> Tornado User's Guide: Shell </i>for more discussion of this issue.</div>
</td>


</tr>
<tr valign="top">
<td></td>

<td><hr></td>


</tr>

<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p callout>



<dl class="margin">

<dd><p class="Body"><a name="85509"> </a>For more information about loader arguments, see the discussion of <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b> (in the reference entry for <b class="command">windsh</b>).</p>
<dd><p class="Body"><a name="85513"> </a>For information about the target-resident version of the loader (which also requires the target-resident symbol table), see the VxWorks reference entry for <b class="library">loadLib</b>.</p>
</dl>

</dl>
<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="85514">8.4.5  &nbsp;&nbsp;Module IDs and Group Numbers</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="85516"> </a>When a module is loaded, it is assigned a module ID and a group number. Both the module ID and the group number are used to reference the module. The module ID is returned by <b class="routine"><i class="routine">ld</i></b><b>(&nbsp;)</b> as well as by the target-resident loader routines. When symbols are added to the symbol table, the associated module is identified by the group number (a small integer). (Due to limitations on the size of the symbol table, the module ID is inappropriate for this purpose.) All symbols with the same group number are from the same module. When a module is unloaded, the group number is used to identify and remove all the module's symbols from the symbol table.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="85519">8.4.6  &nbsp;&nbsp;Unloading Modules</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="85521"> </a>Whenever you load a particular object module more than once, using the target server (from either the shell or the debugger), the older version is unloaded automatically. You can also unload a module explicitly: both the Tornado shell and the target-resident VxWorks libraries include an unloader. To remove a module from the shell, use the shell routine <b class="routine"><i class="routine">unld</i></b><b>(&nbsp;)</b>; see the reference entry for <b class="command">windsh</b>. </p>
<dd><p class="Body"><a name="85526"> </a>For information about the target-resident version of the unloader (which also requires the target-resident symbol table and loader), see the VxWorks reference entry for <b class="library">unldLib</b>.</p>
<dd><p class="Body"><a name="85527"> </a>After a module has been unloaded, any calls to routines in that module fail with unpredictable results. Take care to avoid unloading any modules that are required by other modules. One solution is to link interdependent files using<b class="command"> </b>the static linker<b class="command"> ld</b><i class="textVariable">arch</i> as described in <a href="c-config4.html#85471"><i class="title">8.4.3&nbsp;Static Linking (Optional)</i></a>, so that they can only be loaded and unloaded as a unit.</p>
</dl>

</dl>


<a name="foot"><hr></a>


<p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-config.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-config3.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-config5.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p>

</body>

</html>
<!---
by WRS Documentation (), Wind River Systems, Inc.
    conversion tool:  Quadralay WebWorks Publisher 4.0.11
    template:         CSS Template, Jan 1998 - Jefro --->