不同的編譯器，相同的代碼也會有問題？？��！

polejo

Hi all
完全一樣的uboot代碼，不同的編譯器，區(qū)別只是一個gcc和uclibc版本較新。
編出來的uboot一個可用，一個不可用。

不可用的那個可能是內(nèi)存初始化有問題。flash階段好好的，跳轉(zhuǎn)到 內(nèi)存之后就死掉了。
編譯器對程序有哪些影響？
會不會和GLOBAL_OFFSET_TABLE有關(guān)系呢？
怎么確認和定位？

哪位大神給個思路？

polejo

死在 board_init_r 中，初步確認和code_rellocate 有關(guān)系。
兩個編譯器下 __u_boot_cmd_start 和 __u_boot_cmd_end 不相同，錯誤的那個地址范圍是flash區(qū)域的��！
uboot.lds里的 __u_boot_cmd_start 是根據(jù)什么來確定的呢？

polejo

u-boot.lds中的全局符號在重定向前后地址是不同的，前是flash區(qū)間內(nèi)與system.map地址一致，后是ddr區(qū)間內(nèi)
錯誤的編譯器編出來的uboot為何沒有重定向呢？ 前后都是 flash 區(qū)間的同一地址��！

爻易

相同的代碼，相同的編譯器，不同的優(yōu)化選項，有時也會產(chǎn)生不同的結(jié)果。

匯編程序員不會100％信任編譯器！盡信書則不如無書！

polejo

回復(fù) 4# 爻易

這個知道，所以 uboot 編譯時的 config.mk 和 config.h，連CFLAG LDFLAG 都保證了是一模一樣的。

而且relocate_code的代碼是匯編的，在start.S，非C，并且確認傳入relocate_code的三個參數(shù)都是一模一樣的。

1. * a0 = addr_sp
   
2. * a1 = gd
   
3. * a2 = destination address

復(fù)制代碼

我的疑惑是即便如此，relocate_code() 表現(xiàn)仍不相同。

爻易

相同的編譯標志，不同的字長，如32位升級到64位模式，參數(shù)傳遞方式也可能會變化，匯編與C混編代碼時要特別注意這方面的問題。

lazy_linux

回復(fù) 5# polejo
建議：是否可以對兩個版本的relocate_code代碼進行對比，可以反匯編處理，也許能發(fā)現(xiàn)一點問。


   

polejo

回復(fù) 7# lazy_linux

    relocate_code本身就是匯編寫的，沒有匯編器的參與，不需要反匯編，而且兩個版本的relocate_code一模一樣。

這個問題最終是沒有找到根本原因，只是一個解決的辦法，把壞版本的驅(qū)動逐步移到好版本里面，保證一級啟動的部分都是ok的。

folklore

自已用ldscript指定指令的位置。

amarant

很久前碰過相同的問題，