uboot的relocation原理詳細分析

但基于以前的理解，一個完整可運行的bin文件，link時指定的鏈接地址，load時的加載地址，運行時的運行地址，這3個地址應該是一致的

relocation后運行地址不同于加載地址特別是鏈接地址，ARM的尋址會不會出現問題？

新版uboot跟老版uboot不太一樣的地方在于新版uboot不管uboot的load addr（entry pointer）在哪里，啟動后會計算出一個靠近sdram頂端的地址，將自身代碼拷貝到該地址，繼續運行。

個人感覺uboot這樣改進用意有二，一是為kernel騰出低端空間，防止kernel解壓覆蓋uboot，二是對于由靜態存儲器（spiflash nandflash）啟動，這個relocation是必須的。

但是這樣會有一個問題，relocation后uboot的運行地址跟其鏈接地址不一致，compiler會在link時確定了其中變量以及函數的絕對地址，鏈接地址加載地址 運行地址應該一致，

這樣看來，arm在尋址這些變量函數時找到的應該是relocation之前的地址，這樣relocation就沒有意義了！

當然uboot不會這樣，我們來分析一下uboot下relocation之后是如何尋址的，開始學習之前我是有3個疑問，如下

（1）如何對函數進行尋址調用

（2）如何對全局變量進行尋址操作（讀寫）

（3）對于全局指針變量中存儲的其他變量或函數地址在relocation之后如何操作

搞清楚這3個問題，對于我來說relocation的原理就算是搞明白了。

為了搞清楚這些，在uboot的某一個文件中加入如下代碼

[cpp] view plaincopyprint?

1. voidtest_func(void)
2. {
3. printf("testfuncn");
4. }
6. staticvoid*test_func_val=test_func;
7. staticinttest_val=10;
9. voidrel_dyn_test()
10. {
11. test_val=20;
12. printf("test=0x%xn",test_func);
13. printf("test_func=0x%xn",test_func_val);
14. test_func();
15. }

void test_func(void) { printf("test funcn"); } static void * test_func_val = test_func; static int test_val = 10; void rel_dyn_test() { test_val = 20; printf("test = 0x%xn", test_func); printf("test_func = 0x%xn", test_func_val); test_func(); }

找到rel_dyn_test函數，如下：

[cpp] view plaincopyprint?

1. 80e9d3cc:
2. 80e9d3cc:e59f0000ldrr0,[pc,#0];80e9d3d4
3. 80e9d3d0:eaffc2fbb80e8dfc4
4. 80e9d3d4:80eb1c39.word0x80eb1c39
6. 80e9d3d8:
7. 80e9d3d8:e59f202cldrr2,[pc,#44];80e9d40c
8. 80e9d3dc:e3a03014movr3,#20;0x14
9. 80e9d3e0:e92d4010push{r4,lr}
10. 80e9d3e4:e59f1024ldrr1,[pc,#36];80e9d410
11. 80e9d3e8:e5823000strr3,[r2]
12. 80e9d3ec:e59f0020ldrr0,[pc,#32];80e9d414
13. 80e9d3f0:ebffc2f3bl80e8dfc4
14. 80e9d3f4:e59f301cldrr3,[pc,#28];80e9d418
15. 80e9d3f8:e59f001cldrr0,[pc,#28];80e9d41c
16. 80e9d3fc:e5931000ldrr1,[r3]
17. 80e9d400:ebffc2efbl80e8dfc4
18. 80e9d404:e8bd4010pop{r4,lr}
19. 80e9d408:eaffffefb80e9d3cc
20. 80e9d40c:80eb75c0.word0x80eb75c0
21. 80e9d410:80e9d3cc.word0x80e9d3cc
22. 80e9d414:80eb1c44.word0x80eb1c44
23. 80e9d418:80eaa54c.word0x80eaa54c
24. 80e9d41c:80eb1c51.word0x80eb1c51

80e9d3cc : 80e9d3cc: e59f0000 ldr r0, [pc, #0] ; 80e9d3d4 80e9d3d0: eaffc2fb b 80e8dfc4 80e9d3d4: 80eb1c39 .word 0x80eb1c39 80e9d3d8 : 80e9d3d8: e59f202c ldr r2, [pc, #44] ; 80e9d40c 80e9d3dc: e3a03014 mov r3, #20 ; 0x14 80e9d3e0: e92d4010 push {r4, lr} 80e9d3e4: e59f1024 ldr r1, [pc, #36] ; 80e9d410 80e9d3e8: e5823000 str r3, [r2] 80e9d3ec: e59f0020 ldr r0, [pc, #32] ; 80e9d414 80e9d3f0: ebffc2f3 bl 80e8dfc4 80e9d3f4: e59f301c ldr r3, [pc, #28] ; 80e9d418 80e9d3f8: e59f001c ldr r0, [pc, #28] ; 80e9d41c 80e9d3fc: e5931000 ldr r1, [r3] 80e9d400: ebffc2ef bl 80e8dfc4 80e9d404: e8bd4010 pop {r4, lr} 80e9d408: eaffffef b 80e9d3cc 80e9d40c: 80eb75c0 .word 0x80eb75c0 80e9d410: 80e9d3cc .word 0x80e9d3cc 80e9d414: 80eb1c44 .word 0x80eb1c44 80e9d418: 80eaa54c .word 0x80eaa54c 80e9d41c: 80eb1c51 .word 0x80eb1c51

data段中

[cpp] view plaincopyprint?

1. 80eb75c0:
2. 80eb75c0:0000000a.word0x0000000a

80eb75c0 : 80eb75c0: 0000000a .word 0x0000000a

[cpp] view plaincopyprint?

1. 80eaa54c:
2. 80eaa54c:80e9d3cc.word0x80e9d3cc

80eaa54c : 80eaa54c: 80e9d3cc .word 0x80e9d3cc

rel_dyn_test反匯編后，最后多了一部分從0x80e9d40c開始的內存空間，對比發現這部分內存空間地址上的值竟然是函數需要的變量test_val test_func_val的地址。

網上資料稱這些函數末尾存儲變量地址的內存空間為Label，（編譯器自動分配）

一條條指令來分析。

ldr r2, [pc, #44] ========> r2 = [pc + 0x2c]=======>r2 = [0x80e9d3e0 + 0x2c]=======>r2 =[0x80e9d40c]

需要注意，由于ARM的流水線機制，當前PC值為當前地址加8個字節

這樣r2獲取的是0x80e9d40c地址的值0x80eb75c0，這就是test_val的值嘛

mov r3， #20======> r3 = 20

對應C函數這應該是為test_val = 20做準備，先跳過后面2條指令，發現

str r3, [r2]

很明顯了，將立即數20存入0x80eb75c0中也就是test_val中。

這3條指令說明，ARM對于變量test_val的尋址如下：

（1）將變量test_val的地址存儲在函數尾端的Label中（這段內存空間是由編譯器自動分配的，而非人為）

（2）基于PC相對尋址獲取函數尾端Label上的變量地址

（3）對test_val變量地址進行讀寫操作

再來看其中的幾條指令

ldr r3, [pc, #28] =====> r3 = [0x80e9d3fc + 0x1c] =====> r3 = [0x80e9d418] ====> r3 = 0x80eaa54c

ldr r1, [r3] =====> r1 = [0x80eaa54c] ======> r1 = 0x80e9d3cc

0x80e9d3cc這個地址可以看出是test_func的入口地址，這里是printf打印test_func_val的值
可以看出對于函數指針變量的尋址跟普通變量一樣。

接下來來看函數的調用，可以看到對于printf以及test_func，使用的是指令bl以及b進行跳轉，這2條指令都是相對尋址（pc + offset）

說明ARM調用函數使用的是相對尋址指令bl或b，與函數的絕對地址無關

對于這3種情況的尋址方法已經知道了，那就需要思考一下relocation之后會有什么變化。

將rel_dyn_test relocation之后可以想象，函數的調用還是沒有問題的，因為使用了bl或b相對跳轉指令。

但是對于變量的尋址就有問題了，尋址的前2步沒有問題，相對尋址獲取尾部Label中的變量地址，但獲取的變量地址是在 link時就確定下來的絕對地址啊！

而對于指針變量的尋址呢，問題更多了，

首先跟普通變量尋址一樣，尾部內存空間的變量地址是link時的絕對地址，再者，指針變量存儲的變量指針或者函數指針也是在link時確定的絕對地址，relocation之后這個值也變了！

那uboot是如何來處理這些情況的呢？更準確的說應該是compiler和uboot如何一起來處理這些情況的呢？

這里利用了PIC位置無關代碼，通過為編譯器指定編譯選項-fpic或-fpie產生，
這樣編譯產生的目標文件包含了PIC所需要的信息，-fpic，-fpie是gcc的PIC編譯選項。ld也有PIC連接選項-pie，要獲得一個完整的PIC可運行文件，連接目標文件時必須為ld指定-pie選項，

察看uboot的編譯選項發現，在arch/arm/config.mk，如下：

[cpp] view plaincopyprint?

1. #neededforrelocation
2. LDFLAGS_u-boot+=-pie

# needed for relocation LDFLAGS_u-boot += -pie

指定-pie后編譯生成的uboot中就會有一個rel.dyn段，uboot就是靠rel.dyn段實現了完美的relocation！

察看u-boot.dump中的rel.dyn段，如下：

[cpp] view plaincopyprint?

1. Disassemblyofsection.rel.dyn:
3. 80eb7d54<__rel_dyn_end-0x5c10>:
4. 80eb7d54:80e80020rschir0,r8,r0,lsr#32
5. 80eb7d58:00000017andeqr0,r0,r7,lslr0
6. 80eb7d5c:80e80024rschir0,r8,r4,lsr#32
7. 80eb7d60:00000017andeqr0,r0,r7,lslr0
8. 80eb7d64:80e80028rschir0,r8,r8,lsr#32
9. 80eb7d68:00000017andeqr0,r0,r7,lslr0
10. 。。。
11. "color:#FF0000;">80eba944:80e9d40crschisp,r9,ip,lsl#8
12. 80eba948:00000017andeqr0,r0,r7,lslr0
13. 80eba94c:80e9d410rschisp,r9,r0,lslr4
14. 80eba950:00000017andeqr0,r0,r7,lslr0
15. 80eba954:80e9d414rschisp,r9,r4,lslr4
16. 80eba958:00000017andeqr0,r0,r7,lslr0
17. 80eba95c:80e9d418rschisp,r9,r8,lslr4
18. 80eba960:00000017andeqr0,r0,r7,lslr0
19. 80eba964:80e9d41crschisp,r9,ip,lslr4
20. 80eba968:00000017andeqr0,r0,r7,lslr0
21. 。。。。

Disassembly of section .rel.dyn: 80eb7d54 <__rel_dyn_end-0x5c10>: 80eb7d54: 80e80020 rschi r0, r8, r0, lsr #32 80eb7d58: 00000017 andeq r0, r0, r7, lsl r0 80eb7d5c: 80e80024 rschi r0, r8, r4, lsr #32 80eb7d60: 00000017 andeq r0, r0, r7, lsl r0 80eb7d64: 80e80028 rschi r0, r8, r8, lsr #32 80eb7d68: 00000017 andeq r0, r0, r7, lsl r0 。。。 80eba944: 80e9d40c rschi sp, r9, ip, lsl #8 80eba948: 00000017 andeq r0, r0, r7, lsl r0 80eba94c: 80e9d410 rschi sp, r9, r0, lsl r4 80eba950: 00000017 andeq r0, r0, r7, lsl r0 80eba954: 80e9d414 rschi sp, r9, r4, lsl r4 80eba958: 00000017 andeq r0, r0, r7, lsl r0 80eba95c: 80e9d418 rschi sp, r9, r8, lsl r4 80eba960: 00000017 andeq r0, r0, r7, lsl r0 80eba964: 80e9d41c rschi sp, r9, ip, lsl r4 80eba968: 00000017 andeq r0, r0, r7, lsl r0 。。。。

在arch/arm/lib/relocate.S中

[cpp] view plaincopyprint?

1. ENTRY(relocate_code)
2. ldrr1,=__image_copy_start
3. subsr4,r0,r1
4. beqrelocate_done
5. ldrr2,=__image_copy_end
7. copy_loop:
8. ldmiar1!,{r10-r11}
9. stmiar0!,{r10-r11}
10. cmpr1,r2
11. blocopy_loop
14. ldrr2,=__rel_dyn_start
15. ldrr3,=__rel_dyn_end
16. fixloop:
17. ldmiar2!,{r0-r1}
18. andr1,r1,#0xff
19. cmpr1,#23
20. bnefixnext
23. addr0,r0,r4
24. ldrr1,[r0]
25. addr1,r1,r4
26. strr1,[r0]
27. fixnext:
28. cmpr2,r3
29. blofixloop
31. relocate_done:

ENTRY(relocate_code) ldr r1, =__image_copy_start subs r4, r0, r1 beq relocate_done ldr r2, =__image_copy_end copy_loop: ldmia r1!, {r10-r11} stmia r0!, {r10-r11} cmp r1, r2 blo copy_loop ldr r2, =__rel_dyn_start ldr r3, =__rel_dyn_end fixloop: ldmia r2!, {r0-r1} and r1, r1, #0xff cmp r1, #23 bne fixnext add r0, r0, r4 ldr r1, [r0] add r1, r1, r4 str r1, [r0] fixnext: cmp r2, r3 blo fixloop relocate_done:

來看一下arm的link script，在arch/arm/cpu/u-boot.lds，如下：

[cpp] view plaincopyprint?

1. OUTPUT_FORMAT("elf32-littlearm","elf32-littlearm","elf32-littlearm")
2. OUTPUT_ARCH(arm)
3. ENTRY(_start)
4. SECTIONS
5. {
6. .=0x00000000;
8. .=ALIGN(4);
9. .text:
10. {
11. *(.__image_copy_start)
12. CPUDIR/start.o(.text*)
13. *(.text*)
14. }
16. .=ALIGN(4);
17. .rodata:{*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))}
19. .=ALIGN(4);
20. .data:{
21. *(.data*)
22. }
24. .=ALIGN(4);
26. .=.;
28. .=ALIGN(4);
29. .u_boot_list:{
30. "code"class="cpp">KEEP(*(SORT(.u_boot_list*)));
31. }
33. .=ALIGN(4);
35. .image_copy_end:
36. {
37. *(.__image_copy_end)
38. }
40. .rel_dyn_start:
41. {
42. *(.__rel_dyn_start)
43. }
45. .rel.dyn:{
46. *(.rel*)
47. }
49. .rel_dyn_end:
50. {
51. *(.__rel_dyn_end)
52. }
54. .end:
55. {
56. *(.__end)
57. }
59. _image_binary_end=.;

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { . = 0x00000000; . = ALIGN(4); .text : { *(.__image_copy_start) CPUDIR/start.o (.text*) *(.text*) } . = ALIGN(4); .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } . = ALIGN(4); .data : { *(.data*) } . = ALIGN(4); . = .; . = ALIGN(4); .u_boot_list : {

KEEP(*(SORT(.u_boot_list*))); } . = ALIGN(4); .image_copy_end : { *(.__image_copy_end) } .rel_dyn_start : { *(.__rel_dyn_start) } .rel.dyn : { *(.rel*) } .rel_dyn_end : { *(.__rel_dyn_end) } .end : { *(.__end) } _image_binary_end = .;

可以看出__image_copy_start---end之間包括了text data rodata段，但是沒有包括rel_dyn。 繼續看relocate_code函數，拷貝__image_copy_start----end之間的數據，但沒有拷貝rel.dyn段。 首先獲取__rel_dyn_start地址到r2，將start地址上連續2個4字節地址的值存在r0 r1中 判斷r1中的值低8位，如果為0x17，則將r0中的值加relocation offset。 獲取以此r0中值為地址上的值，存到r1中 將r1中值加relocation offset，再存回以r0中值為地址上。 以此循環，直到__rel_dyn_end。 這樣讀有些拗口。來以咱們的rel_dyn_test舉例子。 上面rel.dyn段中有一段如下： 

[cpp] view plaincopyprint?

1. 80eba944:80e9d40crschisp,r9,ip,lsl#8
2. 80eba948:00000017andeqr0,r0,r7,lslr0

80eba944: 80e9d40c rschi sp, r9, ip, lsl #8 80eba948: 00000017 andeq r0, r0, r7, lsl r0

按照上面的分析，判斷第二個四字節為0x17，r0中存儲為0x80e9d40c。這個是rel_dyn_test末尾Label的地址啊， 將r0加上relocation offset，則到了relocation之后rel_dyn_test的末尾Label。 獲取r0為地址上的值到r1中，0x80eb75c0，可以看到，這個值就是變量test_val的首地址啊。 最后將r1加上relocation offset，寫回以r0為地址上。意思是將變量test_val地址加offset后寫回到relocation之后rel_dyn_test的末尾Label中。 這樣relocate_code完成后，再來看對test_val的尋址。尋址第三步獲取到的是修改之后的relocation addr啊，這樣就可以獲取到relocation之后的test_val值！ 對于普通變量尋址是這樣，那對于指針變量呢，如test_func_val呢？ 獲取test_func_val relocation后地址的步驟跟上面一樣，但是我們在獲取test_func_val的值時要注意，這個變量存儲的是函數test_func指針，之前是0x80e9d3cc，relocation之后就變化了，所以test_func_val的值也應該變化，這個該怎么辦？ 方法是一樣的，可以在rel.dyn段中找到如下一段： 

[cpp] view plaincopyprint?

1. 80ebc18c:80eaa54crschisl,sl,ip,asr#10
2. 80ebc190:00000017andeqr0,r0,r7,lslr0

80ebc18c: 80eaa54c rschi sl, sl, ip, asr #10 80ebc190: 00000017 andeq r0, r0, r7, lsl r0

這上面存儲的是test_func_val的地址，按照relocate_code的操作，完成后80eaa54c + offset上的值也應該+offset了。 這就解決了，test_func_val的值也就是test_func的地址也被修改為relocation之后的地址了。 網上查閱資料，這里對于rel.dyn段中每一個rel section（8個字節）第二個4字節，0x17，是一種label的類型R_ARM_RELATIVE， 經過上面uboot的relocate_code后，我們提出的3個問題的尋址都可以正常工作。 還有一個疑問，是誰來決定哪些label放到rel.dyn中，特別是對于存儲指針的變量，如何分辨，這樣看來，是compiler的ld來完成的這個工作，將所有需要relocate的label放到rel.dyn段中，真是牛逼的compiler??！總結一下，可以看出， 使用-pie選項的compiler，將需要relocate的值（全局變量地址 函數入口地址）的地址存儲在rel.dyn段中，uboot運行中relocate_code遍歷rel.dyn段，根據rel.dyn中存儲的值，對以（這些值+offset）為地址上的值進行了relocate，完成對所有需要relocate的變量的修改！。。。。還是有些拗口。。。 需要注意的是，在uboot的整個relocate_code中rel.dyn不僅沒有拷貝，也沒有修改，修改只是針對rel.dyn中值+offset為地址上的值！ 查閱網上資料，compiler在cc時加入-fPIC或-fPIE選項，會在目標文件中生成GOT（global offset table），將本文件中需要relocate的值存放在GOT中，函數尾部的Label來存儲GOT的offset以及其中變量的offset，變量尋址首先根據尾部Label相對尋址找到GOT地址，以及變量地址在GOT中的位置，從而確定變量地址，這樣對于目標文件統一修改GOT中的值，就修改了變量地址的offset，完成了relocation。 ld時加入-pie選項，就會將GOT并入到rel.dyn段中，uboot在relocate_code中統一根據rel.dyn段修改需要relocation的數值。 uboot中ld使用-pie而cc沒有使用-fPIC或-fPIE,目標文件中就不會生成GOT，函數中尋址還是在尾部Label中直接存儲變量的絕對地址，但這個Label同樣存在rel.dyn中，uboot根據rel.dyn段修改Label上的值，就完成了relocation。 這樣不僅節省了每個目標文件的GOT段，而且不需要去相對尋址GOT，直接修改函數尾部Label所存儲的變量地址就可以啦！ uboot的relocation就是如此！