TQ2440之uboot---4.分析u-boot Makefile 最后连接的过程

1.最后生成u-boot的过程
以下是u-boot Makefile最后连接生成u-boot的过程

UNDEF_SYM=`arm-linux-objdump -x lib_generic/libgeneric.a board/EmbedSky/libEmbedSky.a cpu/arm920t/libarm920t.a cpu/arm920t/s3c24x0/libs3c24x0.a lib_arm/libarm.a fs/cramfs/libcramfs.a fs/jffs2/libjffs2.a net/libnet.a rtc/librtc.a drivers/libdrivers.a drivers/nand/libnand.a drivers/nand_legacy/libnand_legacy.a drivers/lcd/liblcd.a modules/usb.module modules/wince.module common/libcommon.a |sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\

cd /root/embed/opt/EmbedSky/u-boot-1.1.6 && arm-linux-ld -Bstatic -T /root/embed/opt/EmbedSky/u-boot-1.1.6/board/EmbedSky/u-boot.lds -Ttext 0x33D80000 $UNDEF_SYM cpu/arm920t/start.o \

--start-group lib_generic/libgeneric.a board/EmbedSky/libEmbedSky.a cpu/arm920t/libarm920t.a cpu/arm920t/s3c24x0/libs3c24x0.a lib_arm/libarm.a fs/cramfs/libcramfs.a fs/jffs2/libjffs2.a net/libnet.a rtc/librtc.a drivers/libdrivers.a drivers/nand/libnand.a drivers/nand_legacy/libnand_legacy.a drivers/lcd/liblcd.a modules/usb.module modules/wince.module common/libcommon.a --end-group -L /opt/EmbedSky/crosstools_3.4.5_softfloat/gcc-3.4.5-glibc-2.3.6/arm-linux/lib/gcc/arm-linux/3.4.5 -lgcc \

-Map u-boot.map -o u-boot

a. UNDEF_SYM的作用

用objdump -x 列出所有库的头
    用sed 将 __u_boot_cmd_.* 替换成 -u__u_boot_cmd_.*
    sort| uniq 去掉重复的部分
所以执行后 UNDEF_SYM=
-u__u_boot_cmd_autoscr
…...
-u__u_boot_cmd_test_zImage
-u__u_boot_cmd_tftpboot
-u__u_boot_cmd_usbslave

b. arm-linux-ld -Tu-boot.lds -Ttext 0x33D80000

u-boot.lds 中有如下：
. = 0x00000000;
. = ALIGN(4);
.text :
{
cpu/arm920t/start.o (.text)
board/EmbedSky/boot_init.o (.text)
*(.text)
}

b.1虽然 u-boot.lds 是从0x00000000 开始，但是这儿明确的指定了 -Ttext 0x33D80000, 所以生成的u-boot的代码段是从0x33D80000开始的。
b.2 另外 UNDEF_SYM中的一系列的 -u__u_boot_cmd_.*提供给ld
但是还有一点不太明白的就是，为什么要这样做？
参考了这篇文章，对crifan的崇拜有如滔滔江水......

以下引自crifan的《详细分析make uboot 最后的编译链接的具体执行过程 v2012-03-29》

“-u symname
——————————
Enter symname as an undefined symbol in the symbol table. This is useful for loading entirely from an archive library, since initially the symbol table is empty, and an unresolved reference is needed to force the loading of the first routine. The placement of this option on the command line is significant; it must be placed before the library that will define the symbol.
—————————————————————————————————————-
总的意思，就是，在ld的时候，不定义，这些符号，即不定义__u_boot_cmd_asdebug，__u_boot_cmd_base等等这些符号，我的理解是，因为开始需要从某个库中载入其他的符号，而这个时候，还没有载入到那个包含此符号定义的库，所以，暂时先加入这个-u说明，先不定义这些符号，等到所有的库都加载完了，再去找这些符号的定义，此时已经加载完所有的库了，也就能找到这些符号的定义了。
(F)接下来的，就是要ld的，那一堆的目标文件，库文件了：
cpu/arm926ejs/start.o和
–start-group lib_generic/libgeneric.a lib_generic/lzma/liblzma.a cpu/arm926ejs/libarm926ejs.a 。。。。。。 post/libpost.a board/ams/as3536/libas3536.a –end-group
关于–start-group和 –end-group的含义：
-（archives）或者—start-group archives –end-group 参数中间的目标文件会被ld反复搜索，对相互交叉引用的目标文件很有用
所以，我的理解是，如果ld载入了一个库，发现该库中，有UNDF，未被定义的变量，有了这个参数的指示后，就会在这一堆.a和.o文件里面反复搜索，直至找到为止，否则，如果在已经加载的库中，找不到，就会报错。”

关于”–start-group和 –end-group”，又去找了相关资料：

Linker order – GCC

GCC: –start-group and –end-group command line options

得知确切的含义是：

链接器LD去load对应的库（lib，module）的时候，可能会遇到这些情况：

（1）A库，引用了B库中funcInB()，但是先ld A库，导致找不到对应的funInB而链接报错

（2）A库和B库，互相都包含对应所引用到的函数，即互相引用/循环引用，ld编译器会因为找不到A库中所引用的B库的中的函数（或者反过来B库引用A库中的函数）而报错。

此时，用”–start-group和 –end-group“，通知ld链接器，去在–start-group和–end-group中间的这些库函数，多花点时间，对于这些库，都从头到尾，多查几遍，去找找那些还没有找到的所引用的函数，是不是在另外的库中有这些函数，以此解决：

（1）A库引用到了后来才加载的B库中的函数

（2）解决循环引用

之类的问题。