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, cv@no.mail.net)
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 int $(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, dsl@tadpole.co.uk)
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: Michael.Ben-Ari@ecitele.com)
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, OleAsbjornF@scanmar.no)
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...)
STM32
MCU
通讯及无线技术
物联网技术
电子DIY
板卡试用
基础知识
软件与操作系统
我爱生活
小e食堂