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

1. 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`;\
   

2. 
   

3. 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 \
   

4. 
   

5. --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 \
   

6. 
   

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

a. UNDEF_SYM的作用

1. 用objdump -x 列出所有庫的頭
   

2.     用sed 將 __u_boot_cmd_.* 替換成 -u__u_boot_cmd_.*
   

3.     sort| uniq 去掉重復的部分
   

4. 所以執行后 UNDEF_SYM=
   

5. -u__u_boot_cmd_autoscr
   

6. …...
   

7. -u__u_boot_cmd_test_zImage
   

8. -u__u_boot_cmd_tftpboot
   

9. -u__u_boot_cmd_usbslave

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

1. u-boot.lds 中有如下：

2. . = 0x00000000;

3. . = ALIGN(4);

4. .text :

5. {

6. cpu/arm920t/start.o (.text)

7. board/EmbedSky/boot_init.o (.text)

8. *(.text)

9. }

b.1雖然 u-boot.lds 是從0x00000000 開始，但是這兒明確的指定了 -Ttext 0x33D80000, 所以生成的u-boot的代碼段是從0x33D80000開始的。
b.2 另外 UNDEF_SYM中的一系列的 -u__u_boot_cmd_.*提供給ld
但是還有一點不太明白的就是，為什么要這樣做？
參考了這篇文章，對crifan的崇拜有如滔滔江水......
http://www.crifan.com/2010/02/27/detailed_analysis_of_the_make_uboot_final_compile_and_link_the_implementation_process/
以下引自crifan的《詳細分析make uboot 最后的編譯鏈接的具體執行過程 v2012-03-29》

1. “-u symname
   

2. ——————————
   

3. 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.
   

4. —————————————————————————————————————-
   

5. 總的意思，就是，在ld的時候，不定義，這些符號，即不定義__u_boot_cmd_asdebug，__u_boot_cmd_base等等這些符號，我的理解是，因為開始需要從某個庫中載入其他的符號，而這個時候，還沒有載入到那個包含此符號定義的庫，所以，暫時先加入這個-u說明，先不定義這些符號，等到所有的庫都加載完了，再去找這些符號的定義，此時已經加載完所有的庫了，也就能找到這些符號的定義了。
   

6. (F)接下來的，就是要ld的，那一堆的目標文件，庫文件了：
   

7. cpu/arm926ejs/start.o和
   

8. –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
   

9. 關于–start-group和 –end-group的含義：
   

10. -（archives）或者—start-group archives –end-group 參數中間的目標文件會被ld反復搜索，對相互交叉引用的目標文件很有用
    

11. 所以，我的理解是，如果ld載入了一個庫，發現該庫中，有UNDF，未被定義的變量，有了這個參數的指示后，就會在這一堆.a和.o文件里面反復搜索，直至找到為止，否則，如果在已經加載的庫中，找不到，就會報錯。”
    

12. 
    

13. 關于”–start-group和 –end-group”，又去找了相關資料：
    

14. 
    

15. Linker order – GCC
    

16. 
    

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

18. 
    

19. 得知確切的含義是：
    

20. 
    

21. 鏈接器LD去load對應的庫（lib，module）的時候，可能會遇到這些情況：
    

22. 
    

23. （1）A庫，引用了B庫中funcInB()，但是先ld A庫，導致找不到對應的funInB而鏈接報錯
    

24. 
    

25. （2）A庫和B庫，互相都包含對應所引用到的函數，即互相引用/循環引用，ld編譯器會因為找不到A庫中所引用的B庫的中的函數（或者反過來B庫引用A庫中的函數）而報錯。
    

26. 
    

27. 此時，用”–start-group和 –end-group“，通知ld鏈接器，去在–start-group和–end-group中間的這些庫函數，多花點時間，對于這些庫，都從頭到尾，多查幾遍，去找找那些還沒有找到的所引用的函數，是不是在另外的庫中有這些函數，以此解決：
    

28. 
    

29. （1）A庫引用到了后來才加載的B庫中的函數
    

30. 
    

31. （2）解決循環引用
    

32. 
    

33. 之類的問題。

34.