不同的編譯器，相同的代碼也會(huì)有問(wèn)題？？！！

polejo

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

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

哪位大神給個(gè)思路？

polejo

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

polejo

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

爻易

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

匯編程序員不會(huì)100％信任編譯器！盡信書(shū)則不如無(wú)書(shū)！

polejo

回復(fù) 4# 爻易

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

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

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

復(fù)制代碼

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

爻易

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

lazy_linux

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


   

polejo

回復(fù) 7# lazy_linux

    relocate_code本身就是匯編寫(xiě)的，沒(méi)有匯編器的參與，不需要反匯編，而且兩個(gè)版本的relocate_code一模一樣。

這個(gè)問(wèn)題最終是沒(méi)有找到根本原因，只是一個(gè)解決的辦法，把壞版本的驅(qū)動(dòng)逐步移到好版本里面，保證一級(jí)啟動(dòng)的部分都是ok的。

folklore

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

amarant

很久前碰過(guò)相同的問(wèn)題，