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_.*)/-u1/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 去掉重復(fù)的部分
所以執(zhí)行后 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
但是還有一點(diǎn)不太明白的就是，為什么要這樣做？
參考了這篇文章，對crifan的崇拜有如滔滔江水......
http://www.crifan.com/2010/02/27/detailed_analysis_of_the_make_uboot_final_compile_and_link_the_implementation_process/
以下引自crifan的《詳細(xì)分析make uboot 最后的編譯鏈接的具體執(zhí)行過程 v2012-03-29》
“-u symname
——————————
Enter symname as an undefined symbolinthe symbol table.Thisisusefulforloading entirely from an archive library,since initially the symbol tableisempty,andan unresolved referenceisneededtoforce the loading of the first routine.The placement of thisoptiononthe command lineissignificant;it must be placed before the library that will define the symbol.
—————————————————————————————————————-
總的意思，就是，在ld的時候，不定義，這些符號，即不定義__u_boot_cmd_asdebug，__u_boot_cmd_base等等這些符號，我的理解是，因?yàn)殚_始需要從某個庫中載入其他的符號，而這個時候，還沒有載入到那個包含此符號定義的庫，所以，暫時先加入這個-u說明，先不定義這些符號，等到所有的庫都加載完了，再去找這些符號的定義，此時已經(jīng)加載完所有的庫了，也就能找到這些符號的定義了。
(F)接下來的，就是要ld的，那一堆的目標(biāo)文件，庫文件了：
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
關(guān)于–start-group和 –end-group的含義：
-（archives）或者—start-group archives –end-group 參數(shù)中間的目標(biāo)文件會被ld反復(fù)搜索，對相互交叉引用的目標(biāo)文件很有用
所以，我的理解是，如果ld載入了一個庫，發(fā)現(xiàn)該庫中，有UNDF，未被定義的變量，有了這個參數(shù)的指示后，就會在這一堆.a和.o文件里面反復(fù)搜索，直至找到為止，否則，如果在已經(jīng)加載的庫中，找不到，就會報錯?！?br/>
關(guān)于”–start-group和 –end-group”，又去找了相關(guān)資料：
Linker order – GCC
GCC:–start-groupand–end-group command line options
得知確切的含義是：
鏈接器LD去load對應(yīng)的庫（lib，module）的時候，可能會遇到這些情況：
（1）A庫，引用了B庫中funcInB()，但是先ld A庫，導(dǎo)致找不到對應(yīng)的funInB而鏈接報錯
（2）A庫和B庫，互相都包含對應(yīng)所引用到的函數(shù)，即互相引用/循環(huán)引用，ld編譯器會因?yàn)檎也坏紸庫中所引用的B庫的中的函數(shù)（或者反過來B庫引用A庫中的函數(shù)）而報錯。
此時，用”–start-group和 –end-group“，通知ld鏈接器，去在–start-group和–end-group中間的這些庫函數(shù)，多花點(diǎn)時間，對于這些庫，都從頭到尾，多查幾遍，去找找那些還沒有找到的所引用的函數(shù)，是不是在另外的庫中有這些函數(shù)，以此解決：
（1）A庫引用到了后來才加載的B庫中的函數(shù)
（2）解決循環(huán)引用
之類的問題。
下載文檔
