vxworks中文faq.txt

vxworks中文FAQ

好运行环境了，不再需要main函数了。
(From: Ilia, [e-mail])

2.1.5 我生成了2.95.2版本的编译器，一切正常，但当我开始链接我的映象时，出现了错误，下面是我
链接ctdt表时的错误：
ctdt.o(.data+0x3c):fake: undefined reference to `global constructors keyed to 
_constructor_name_
... 许多类似的错误，有谁见过这种错误吗？

A: 该问题是由gcc（ver2.7.2-2.95.2）试图改变它得到静态构造函数的方法引起的。它不再对每个构造静
态对象的模块消除函数，该方法是vxworks在编译链接过程中采用的方法。
你可以按如下修改gcc 2.95.2源代码后，恢复原先的操作。
in [source code dir]/gcc/config/arm/vxarm.h, at the very end, add:- 
/*     More DK patches: we undef these two in order to force the  */
/*  compiler to output our static constructors and destructors    */
/*  in the fashion to which it is accustomed....                  */

#undef ASM_OUTPUT_CONSTRUCTOR
#undef ASM_OUTPUT_DESTRUCTOR

/*     This one is so that GLOBAL_THING gets a $ in it's name     */
#undef NO_DOLLAR_IN_LABEL

现在更换到你的编译目录，敲入make clean命令，然后重新编译和安装编译器。我采用这种方法是可以的
，PPC版本的。它使得编译器使用老的方法来making munchable constructors。
希望对你也有帮助。
(From: Dave Korn)

2.1.6 在我编译时，我在编译窗口看到如下输出：
nm386 -g partialImage.o @B:\Sources\Components\Common\Common_Geni_Test\Src\prjObjs.lst | \
wtxtcl D:\Tornado\host\src\hutils\munch.tcl -asm 386 > ctdt.c
   ...
cc386 -nostdlib -r -Wl,-X  partialImage.o ctdt.o -o VxWorksGeniServerTestExe.out
最后一步(linking partialImage.o to ...out)花了很长时间（半个小时），谁有解决办法？
A: 这个可能是munching过程,而不是链接，花了半小时。有人曾贴了一个小窍门来加速。
在munch命令管道里使用"grep GLOBAL"如：

nm386 -g partialImage.o @B:\Sources\Components\Common\Common_Geni_Test\Src\prjObjs.lst 
| grep GLOBAL | \
wtxtcl D:\Tornado\host\src\hutils\munch.tcl -asm 386 > ctdt.c

(From: Dave Korn)


2.1.7 怎样定义一个没有空洞的结构。
Q: How do define a structure without holes in it?

A: 我在vxworks中使用GNU编译器
struct ex {
INT8  source;
INT32 txSize;
INT32 datSize;
INT16 cmd;
} __attribute__ ((packed));

typedef struct ex PackedStruct;
注意：如果可能，避免使用-fpack-struct编译器开关。我门最近移除了这个选项，使得我们的C++程序提
高了30%-100%的性能。这是因为每次存取结构或类里多字节值时，都是一个一个字节操作的。可以使用
__attribute__ ((packed)) 方法代替。
(From: Mark Fanara, [e-mail], and Francisco Pataro, [e-mail])


2.1.8 我怎样在一个C程序文件里调用一个C++函数？

A: 如果你想在一个C程序文件里调用一个C++函数，C++函数必须用extern "C"声明;否则编译器将破坏函数
名，把参数类型说明加在函数名末尾，并返回该函数。
(From: Dave Korn)

2.1.9 -fvolatile开关真的需要吗？
A: WRS建议我们在编译kernel/BSP时，使用-fvolatile开关。它通常缺省打开某个target/h/make/目录下的
文件。
    我们也在我们的应用程序编译过程中使用-fvolatile开关，因为我们参考一些tornado的makefile。
当我们移除该开关后，就碰到一些微妙的BUG，如果你编写驱动程序应当小心。
    -fvolatile开关使编译器生成非常conservative的代码。通过指针使变量值增加(p->x++)不可能如你
想象的在一条指令里完成(68k example):

    addql #1,a0@(8)
如果采用-fvolatile 开关你会得到：
    movel a0@(8),d0
    addql #1,d0
    movel d0,a0@(8)
    movel a0@(8),d0
You can imagine what a C++ application using the "this" pointer everywhere gets compiled into! 
(From: Chris Varlese, [e-mail])

2.1.10 我链接了许多档案文件，现在链接器在解析文件之间的交叉参考时出现了问题？
A: 试试下面的方法

1、把$(LIBS)替换成$(LD_PARTIAL) -o vxWorks.tmp $(MACH_DEP) usrConfig.o version.o 
$(LIBS) (在target/h/rules.bsp文件中)。 Now LD_PARTIAL is ccxxx, so you need to specify -Wl,
--group-start to get cc to pass the argument to ld. 
2、Try adding a -Usymbol for each symbol that has to be pulled in early. 
3、如果办法2 make ld行太笨拙，生成一个.s文件，包含每个没定义的符号和加到链接里的。
4、如果你工作UNIX下，它应该可能得到ld生成没有定义的所要求的列表。你需要加一个循环，就象下面一
样：
/*这是原文，我翻译不好。
1、$(LIBS) is substituted into: $(LD_PARTIAL) -o vxWorks.tmp $(MACH_DEP) usrConfig.o version.o 
$(LIBS) (in target/h/rules.bsp for a non-project build). Now LD_PARTIAL is ccxxx, so you need 
to specify -Wl,--group-start to get cc to pass the argument to ld. 
2、Try adding a -Usymbol for each symbol that has to be pulled in early. 
3、If (2) make the ld line too unwieldy, generate a .s file that contains: .extern symbol for 
each undefined symbol and include that into the link before the libraries 
4、If your building on unix, it ought to be possible get ld to generate the required list of 
undefines! You need to add a loop! Something like this might work: 
*/
        [ ! -f undefs.s ] && echo "#" >undefs.s
        while
                $(CC) -c $(CFLAGS) undefs.s
                $(LD_PARTIAL) -o vxWorks.tmp $(MACH_DEP) usrConfig.o version.o \
                        undefs.o $(LIBS)
                $(NM) vxWorks.tmp | grep ' __' | $(MUNCH) > ctdt.c
                $(MAKE) CC_COMPILER="-fdollars-in-identifiers" ctdt.o
        do
                $(LD) $(LDFLAGS) -e $(SYS_ENTRY) $(LD_LOW_FLAGS) -o vxWorks \
                   dataSegPad.o vxWorks.tmp ctdt.o tad_hook_list.o 2>&1 | tee ld.errs |
                        while read file undef ref to symbol
                        do
                                [ "$undef" = "undefined" ] || continue
                                [ "$ref" = "reference" ] || continue
                                [ "$to" = "to" ] || continue
                                oifs="$IFS"
                                IFS="'/`"
                                symbol="`echo $symbol`"
                                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
当然它需要另一系列的ESC和; \在每一行，以使得可以在make下运行。
(我也重新构造了原始的rules.bsp内容，我的可能与vxWorks原来的有些不同。)
(From: David Laight, [e-mail])



2.1.11 警告"trigraphs occured"是什么意思?
A: 对Tornado或Vxoworks没什么要做的。
你可能在你代码（也可能在注释里）中有三字符序列--参看K&R (Kernighan & Ritchie; A12.1 - 这是
ANSI 新引进的。-- 但是GNU手册里提示"You don't want to know about this brain-damage..." 
使用-ansi或-trigraphs开关，或更好的办法消除任何包含三字符序列'??X'的注释。 (参看K&R书中对X
的定义)。
(From: [e-mail])

2.1.12 为什么编译的最后步骤时间这么长？
生成.out步骤如下：
  1) 链接应用程序和库到partialImage.o
  2) 使用partialImage.o解析出所有静态类（munch）
  3) 编译上面发现的(ctdt.o)
  4) 用ctdt.o链接第一个obj文件partialImage.o
我们的应用程序.out文件有10M，但是多数是调试信息，size386返回只有1M。
我们的下载文件生成需要超过5分钟，Step #1-3正常需要35秒！但是step #4 需要很多时间，整个过程需
要5分30秒。

A: 我不知道为什么这样？但是我们在step #4不重新使用partialImage.o 而是重新生成它，整个过程45s.

(是ld386没有对符号过滤进行优化的原因吗？)
我只是修改了tornado\target\h\make\rules.vxApp文件，它包含制作应用程序的规则。我修改了上面
提到的step $4代码如下:
把$(LD_PARTIAL) $(LD_PARTIAL_LAST_FLAGS) partialImage.o ctdt.o -o $@
替换成$(LD_PARTIAL) $(PRJ_OBJS_FOR_LD_PARTIAL) $(PRJ_LIBS) ctdt.o -o $@

(From: Ole Asbjorn Fadum, [e-mail])

Some more information. 
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

    od -bv $infile |
    sed -e "s/^[0-9]*[ ]*//;
    s/ /, 0/g;
    /^[0-9a-fA-F][0-9a-fA-F]/s/^/ .byte 0/"

(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). 
The above is terribly slow... Slightly faster (under solaris) is:

    od -An -v -tu1 $infile | tr ' ' ',' |
    sed -e 's/,00*\([0-9]\)/,\1/g;s/^,/      .byte   /'

However it is clear that a C program would be even faster... It was still sluggish using 
printf, so...

    char map[256][4];
    for (count = 0; count <= 256; count++)
        sprintf( map[ count ], "%d", count );

    for (;;) {
        count = read( input_fd, buf, BLK_SZ );
	if (count <= 0)
            break;
	    for (off = 0; off < count; off++) {
            if (off & 15)
                putchar( ',' );
            else
                fputs( "\n      .byte   ", stdout  );
            fputs( map[ buf[ off ] ], stdout );
        }
    }

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... 
Build (compiling one small object) just took 6m50 - was over 10 minutes before I played 
with binToAsm!

Ages ago I sped up 'munch' - by grepping out most of the symbols it isn't interested in...

nmarm vxWorks.tmp | tee vxWorks.nm | grep " __" | munch > ctdt.c

(I use the symbol table from this stage for a variety of things...) 
(From: David Laight, [e-mail])





2.1.13 怎样把一个段装载到特定的绝对地址？
A: 我曾包含一个脚本做这些工作，最方便得到这个脚本的方法是使用--verbose开关运行你的链接器，例
如： 
"ldarm --verbose". 编辑这个文件加入类似如下的段落，
  .text  0x8000 : {
[omit]
        . = ALIGN(0x8000);
        /* Create a 8k section of all 0xffff, first value is jump. */
        FILL(0xffff);
        LONG(0xeb000004);
        . = ALIGN(0x2000);
[...]
这将把数据放到任何你想放的地方，在程序被链接时新的链接器脚本必须使用-T参数。
(From: Bill Pringlemeir, [e-mail])

2.1.14 我在使用C++类型的注释时，出现错误，怎样改变它？
A: 一种方法是移除-ansi开关。然而，你可能希望保留你的源代码与ANSI兼容；所以我更喜欢代码能在每
个地方都能编译。传递"-Wp,-lang-c"参数只能使CPP的注释方法可以使用。下面来自预编译器文档
`-lang-c', `-lang-c89', `-lang-c++' 
`-lang-objc', `-lang-objc++' 
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 .

(From: Bill Pringlemeir, [e-mail])

2.1.15 我在编译时碰到了关于cc1参数/选项的错误？
A: 这个可能是由于安装了Cygwin 或DJGPP引起的。当该版本的编译器在路径里先于Tornado版本Cygwin的
GCC被调用时，这个版本不知道这些参数或选项。这个问题可以通过卸载该软件或确定Tornado版本的编译器
在路径环境变量里是头一个后解决。