vxw_pt1.html

vxworks及tornado常见问题解答

                                IFS="$oifs"
                                echo "\t.extern\t$symbol"
                        done | sort -u - undefs.s >undefs.new
                cmp -s undefs.s undefs.new && break
                mv undefs.new undefs.s
        done
        cat ld.errs
</pre>
Of course it need another set of escapes and ; \ on each line to run under make.
</li></ol>
(I've also had to reconstruct the original rules.bsp contents - mine is somewhat
different from the vxWorks original in this area!)

<br>(From: David Laight, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.1-K"></a>

<p>Q: What does the warning "trigraphs occured" mean?
<p>A: This has NOTHING to do with Tornado or VxWorks (per se)

<br>You most probably have in your code (EVEN in COMMENTS)
a trigraph sequence -- see K&amp;R (Kernighan &amp; Ritchie; A12.1 -
This is new to the ANSI standard -- But as the GNU manual states
"You don't want to know about this brain-damage..."

<br>use the -ansi switch or -trigraphs switch upon compilation...

<br>Or better yet, get rid of any comments that comtain a trigraph
sequence '??X' (see K&amp;R for definitions of X).

<br>(From: [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.1-L"></a>

<p>Q: Why does the final stage of compilation take so long?
<p>Q (long): The generation of a '.out' file is as follows:
<ol>
<li>link the application and libraries to partialImage.o</li>
<li>use partialImage.o to extract all static classes (munch)</li>
<li>compile the above findings (ctdt.o)</li>
<li>link the first obj file partialImage.o with ctdt.o</li>
</ol>

<p>Our application ('.out) file is about 10 Mb of code, but this is
mostly because of debug symbols, size386 returns a size of about 1 Mb.

<p>The regeneration of our downloadable file takes in excess of 5 minutes.
Step #1-3 runs at good speed (total 0:35)!!!, but the step #4 takes a lot
of time, making the complete cycle 5:30.

<p>A: I don't know why, but if we don't reuse the partialImage.o in step
#4, but regenerate it, the whole cycle is completed in about 0:45!

<br>(Has ld386 problems with opening large object files due to non
optimal algorithms for symbol parsing??)

<p>What I have done:
<br>tornado\target\h\make\rules.vxApp
contain the rules of how to make an application. I have changed the
above mentioned step $4 which is was as follows:
<pre>
$(LD_PARTIAL) $(LD_PARTIAL_LAST_FLAGS) partialImage.o ctdt.o -o $@
</pre>
with the following:
<pre>
$(LD_PARTIAL) $(PRJ_OBJS_FOR_LD_PARTIAL) $(PRJ_LIBS) ctdt.o -o $@
</pre>
(From: Ole Asbjorn Fadum, [e-mail])

<p><a NAME="1.1-L2"></a>Some more information.
<br>For a variety of reasons I've had to do a few build on a slow system.
One bit that seemed exceptionally slow is the 'binToAsm' call (just
after the 'deflate' generating vxWorks.Z.s)

This is done by <pre>od -bv $infile |
   sed -e "s/^[0-9]*[ ]*//;
    s/ /, 0/g;
    /^[0-9a-fA-F][0-9a-fA-F]/s/^/ .byte 0/"</pre>

(ie use od to generate a list of octal bytes, remove the offset, change
the spaces to comma, add the directive - an extra 0 is added to each
number to ensure they are octal).

<br>The above is terribly slow...
Slightly faster (under solaris) is:
<pre>od -An -v -tu1 $infile | tr ' ' ',' |
	sed -e 's/,00*\([0-9]\)/,\1/g;s/^,/      .byte   /'</pre>

However it is clear that a C program would be even faster...
It was still sluggish using printf, so...
<pre>
    char map[256][4];
    for (count = 0; count &lt;= 256; count++)
        sprintf( map[ count ], "%d", count );

    for (;;) {
        count = read( input_fd, buf, BLK_SZ );
	if (count &lt;= 0)
            break;
	    for (off = 0; off &lt; count; off++) {
            if (off &amp; 15)
                putchar( ',' );
            else
                fputs( "\n      .byte   ", stdout  );
            fputs( map[ buf[ off ] ], stdout );
        }
    }
</pre>
now the system is spending very little of its time doing this bit (it was
a lot slower than the deflate!)

If you are using gcc/gas you can pipe EXTRACT_BIN, COMPRESS, BINTOASM
directly into AS - saving that massive intermediate file...

<br>Build (compiling one small object) just took 6m50 - was over 10 minutes
before I played with binToAsm!

<p>Ages ago I sped up 'munch' - by grepping out most of the symbols it
isn't interested in...
<pre>
nmarm vxWorks.tmp | tee vxWorks.nm | grep " __" | munch &gt; ctdt.c
</pre>
(I use the symbol table from this stage for a variety of things...)
<br>(From: David Laight, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.1-M"></a>

<p>Q: How can I load a segment at a specific absolute address?
<p>A: I have included a script to do this.  The easiest way to get a script
is to run your linker with the `<code>--verbose</code>' flag.  Eg, <code>"ldarm --verbose</code>".
<br>Edit the file to add a statement like this,
<pre>
  .text  0x8000 : {
[omit]
        . = ALIGN(0x8000);
        /* Create a 8k section of all 0xffff, first value is jump. */
        FILL(0xffff);
        LONG(0xeb000004);
        . = ALIGN(0x2000);
[...]
</pre>
This will place the data at what ever address you like.  The new linker
script must be passed with the -T option when the image is built.

<br>You linker might be called ldppc or ldmips or ldx86 etc.
<br>(From: Bill Pringlemeir, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.1-N"></a>

<p>Q: I get an error when I use C++ style comment. How can I change this?
<p>A: One way to do this is by removing the -ansi switch.  However, you may
wish to keep your source base ANSI compliant.  I do use builtin
alloca() and other functions occasionally; but I prefer the code to
compile anywhere.  Passing the "-Wp,-lang-c" argument should only
enable CPP comments.  Here is the comment from the pre-processor docs,

<pre>
`-lang-c', `-lang-c89', `-lang-c++' 
`-lang-objc', `-lang-objc++' 
</pre>
<blockquote>
     Specify the source language. `-lang-c' is the default; it allows
     recognition of C++ comments (comments that begin with `//' and
     end at end of line), since this is a common feature and it will
     most likely be in the next C standard. `-lang-c89' disables
     recognition of C++ comments.  `-lang-c++' handles C++ comment
     syntax and includes extra default include directories for
     C++. `-lang-objc' enables the Objective C `#import'
     directive. `-lang-objc++' enables both C++ and Objective C
     extensions. These options are generated by the compiler driver
     gcc, but not passed from the `gcc' command line unless you use
     the driver's `-Wp' option .
</blockquote>
(From: Bill Pringlemeir, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.1-O"></a>

<p>Q: When I compile I get the errors about parameters/options to cc1.
<p>A: This can be caused by another installation of Cygwin or
DJGPP on your machine. When this version is in the path before
the Tornado version of Cygwin its version of GCC (and CC1) gets
called, and this version probably does not know these parameters
or options.
<br>This problem can be solved by removing the other installation
or by ensuring that the Tornado version is the first version in
the path.

<p>
<hr WIDTH="60%">

<p><h3><a NAME="1.2"><center>1.2 Debugger</center></a></h3>

<a NAME="1.2-A"></a>
Q: How do I use a "plain" version of GDB to debug my target, so without
using Tornado?
<p>A: gdb compiles 'out of the box' for vxworks.

<ul>
<li>go to cygnus (sourceware.cygnus.com), get the latest version of 'insight',
which is gdb + cygnus' UI.</li>
<li>run "<code>configure --target=mips-wrs-vxworks</code>". Change 'mips'
to your processor architecture.</li>
<li>run 'make'</li>
</ul>

This works on win32 if you have cygnus 'cygwin' installed.
It works on Unix systems as is.

<p>RDB is windriver's previous generation debugging protocol, now
replaced by Tornado's 'wdb'. There seems to be no public released
wdb bits, despite the fact that Tornado is clearly using gdb.
You may have to configure RDB into your system (INCLUDE_RDB) and disable
WDB (remove INCLUDE_WDB) to get it to go.

<br>(From: Don Bowman, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.2-B"></a>

<p>Q: How do I stop a task after creation, so I can debug it from the start?
<p>A: Goto tools-&gt;options and on debugger tab and select
always halt after attaching a task
as well as Auto Attach to task -&gt; Always

<br>Now put a global breakpoint (Shift F9) on 'subTask' and after it hit the
breakpoint you have to detach from mainTask.

<br>(From: Chacha Hindustani, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.2-C"></a>

<p>Q: Why can't I see breakpoints when examining memory using the shell?
<p>A: The shell is an unbreakable task, so all the time it is running
the breakpoints are not installed.  When a context switch causes a breakable
task to run, the breakpoints will be resinstated.
<br>So, to see the breakpoint in memory simply spawn the d() command or
l() command. That will then run in a breakable task, and you should
see the magic code inserted to cause an exception.
<br>(From: John, [e-mail])

<p>
<hr WIDTH="60%">

<p><h3><a NAME="1.3"><center>1.3 FTP</center></a></h3>
FTP related questions have been moved to
<a href="vxw_pt4.html#4.4">part 4.4</a>.

<p>
<hr WIDTH="60%">

<p><h3><a NAME="1.4"><center>1.4 Host tools</center></a></h3>

<a NAME="1.4-A"></a>
Q: I made a rom based version of VxWorks (vxWorks_rom), but when I try to 
convert this to a bin version (vxworks_rom.bin) using elftobin I get the
following error:
<pre>C:\project\Project3\default\elftobin &lt;vxWorks_rom&gt; vxWorks_rom.bin
 seg1 : Expected load address 0xfff00100 but file address is 0x00111670</pre>
How can I convert this image to a binary format?
<p>A: This problem has only been reported for PPC architecture.
<br>This problem is known as SPR#8845. There is an updated version of
elftobin available for this problem. Ask you sales representative or service
engineer for this version.

<p>
<hr WIDTH="50%">
<a NAME="1.4-B"></a>

<p>Q: How do I write a WTX tool?
<p>A: I had write a WTX tool under Tornado 1.0.1 and Windows NT 4.0 and began
by following the detailed example and explicit build/link instructions
found in the Tornado API guide. Not even close to building, let alone
working on my setup. 

<br>To be fair, I am compiling with Visual Studio C++, version 6, but there
are still a lot of things missing, regardless of compiler versions. And
I know I could be much more suave and sophisticated by using environment
variables in the paths, but sometimes you just need to get it done.

So here are the mods/clarifications:
<ol>
<li>Source code placed in $(WIND_BASE)\host\src\wtxtest. Example source
did not show up in my install, or anybody else's machine that I could
check, as stated in the manual.</li>
<li>Source code modified as shown below (mostly signal handler code mods
and added includes, the other mods are specific to my application)</li>
<li>Added the following to Project settings, C/C++, Preprocessor:
<ul>
<li>Additional Include directories (path was wrong):
C:\Tornado_03\share\src\wtx,C:\Tornado_03\host\include</li>
<li>Preprocessor Definitions:  HOST (this wasn't listed anywhere, lots 'o'
pain finding, absolutely required)</li></ul></li>
<li>Added the following to Project settings, Link, General (path was wrong):
C:\Tornado_03\host\x86-win32\lib\wtxapidll-d.lib</li>
<li>Added the environment variable WIND_REGISTRY to Win NT, set to my
registry location.  Lots and lots of pain 	and digging to find this
one.  Manual refers to a wtxEnvironSet() call that doesn't exist and is 
listed out of order in various places . Windsurf says it doesn't exist,
and don't bother using it. The 	docs for the nonexistent function
provide a confused set of references to all other tools using this 
function.  WIND_REGISTRY was not set on my machine; all tornado tools
are happy without it; my tool 	could not find the registry.  Set it and
poof!, registry found, tool works.  Make sure you add the 	wtxProbe()
call to check for the registry (and the variable being set), it will
save a lot of grief.</li>
<li>I also modified the tool sample code. This can be found <a href="wtxSample.c">here</a></li>
</ol>
(From: Christopher A Leddy, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.4-C"></a>

<p>Q: When I execute wtxwish I get an error about the init.tcl file.
<p>A: Don't forget to set the TCL_LIBRARY and TK_LIBRARY environment variables to
$(WIND_BASE)/host/tcl/tcl and $(WIND_BASE)/host/tcl/tk. The init.tcl file is
located te TCL_LIBRARY path. The tk.tcl file is located in the TK_LIBRARY
directory. Do not use the $(WIND_BASE) variable, but the actual path. Then
execute the following from your TCL/TK directory:
<pre>
wtxwish &lt;yourTclFile&gt;
</pre>
(From: DrDiags, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.4-D"></a>