TQ2440之uboot---4.分析u-boot Makefile 最后連接的過(guò)程
1.最后生成u-boot的過(guò)程
以下是u-boot Makefile最后連接生成u-boot的過(guò)程
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 列出所有庫(kù)的頭
用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 開(kāi)始，但是這兒明確的指定了 -Ttext 0x33D80000, 所以生成的u-boot的代碼段是從0x33D80000開(kāi)始的。
b.2 另外 UNDEF_SYM中的一系列的 -u__u_boot_cmd_.*提供給ld
但是還有一點(diǎn)不太明白的就是，為什么要這樣做？
參考了這篇文章，對(duì)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í)行過(guò)程 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的時(shí)候，不定義，這些符號(hào)，即不定義__u_boot_cmd_asdebug，__u_boot_cmd_base等等這些符號(hào)，我的理解是，因?yàn)殚_(kāi)始需要從某個(gè)庫(kù)中載入其他的符號(hào)，而這個(gè)時(shí)候，還沒(méi)有載入到那個(gè)包含此符號(hào)定義的庫(kù)，所以，暫時(shí)先加入這個(gè)-u說(shuō)明，先不定義這些符號(hào)，等到所有的庫(kù)都加載完了，再去找這些符號(hào)的定義，此時(shí)已經(jīng)加載完所有的庫(kù)了，也就能找到這些符號(hào)的定義了。
(F)接下來(lái)的，就是要ld的，那一堆的目標(biāo)文件，庫(kù)文件了：
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)文件會(huì)被ld反復(fù)搜索，對(duì)相互交叉引用的目標(biāo)文件很有用
所以，我的理解是，如果ld載入了一個(gè)庫(kù)，發(fā)現(xiàn)該庫(kù)中，有UNDF，未被定義的變量，有了這個(gè)參數(shù)的指示后，就會(huì)在這一堆.a和.o文件里面反復(fù)搜索，直至找到為止，否則，如果在已經(jīng)加載的庫(kù)中，找不到，就會(huì)報(bào)錯(cuò)?！?br/>
關(guān)于”–start-group和 –end-group”，又去找了相關(guān)資料：
Linker order – GCC
GCC:–start-groupand–end-group command line options
得知確切的含義是：
鏈接器LD去load對(duì)應(yīng)的庫(kù)（lib，module）的時(shí)候，可能會(huì)遇到這些情況：
（1）A庫(kù)，引用了B庫(kù)中funcInB()，但是先ld A庫(kù)，導(dǎo)致找不到對(duì)應(yīng)的funInB而鏈接報(bào)錯(cuò)
（2）A庫(kù)和B庫(kù)，互相都包含對(duì)應(yīng)所引用到的函數(shù)，即互相引用/循環(huán)引用，ld編譯器會(huì)因?yàn)檎也坏紸庫(kù)中所引用的B庫(kù)的中的函數(shù)（或者反過(guò)來(lái)B庫(kù)引用A庫(kù)中的函數(shù)）而報(bào)錯(cuò)。
此時(shí)，用”–start-group和 –end-group“，通知ld鏈接器，去在–start-group和–end-group中間的這些庫(kù)函數(shù)，多花點(diǎn)時(shí)間，對(duì)于這些庫(kù)，都從頭到尾，多查幾遍，去找找那些還沒(méi)有找到的所引用的函數(shù)，是不是在另外的庫(kù)中有這些函數(shù)，以此解決：
（1）A庫(kù)引用到了后來(lái)才加載的B庫(kù)中的函數(shù)
（2）解決循環(huán)引用
之類(lèi)的問(wèn)題。
下載文檔
