共享库中的位置无关代码（PIC）
原作者：Eli Bendersky
http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
在之前的文章里我已經描述過在將共享庫載入程序地址空間時需要特殊的處理。簡而言之，在鏈接器創建共享庫時，它不能預先知道這個庫將在哪里載入。這給在庫里訪問數據與代碼帶來了麻煩，應該使得這些訪問指向正確的內存位置。
在Linux ELF共享庫里解決這個問題有兩個主要途徑：
1.??????載入時重定位
2.??????位置無關代碼（PIC）
載入時重定位已經說過了。這里，我想解釋第二個方法——PIC。
一開始我計劃在本文里同時關注x86與x64（即x86-64），但隨著文章越來越長，我發現這是不現實的。因此我將僅解釋PIC在x86上如何工作，選擇這個更老的架構是因為（不像x64）它設計時沒有考慮PIC，因此實現PIC有一點棘手。將來的一篇文章（希望篇幅可以大大縮短）將在這篇的基礎上解釋如何在x64上實現PIC。
載入時重定位的一些問題
正如我們在之前文章里看到的，載入時重定位是一個相當簡單的方法，并且奏效。不過時至今日PIC要流行得多，是構建共享庫的推薦方法。為什么會這樣？
載入時重定位有幾個問題：它需要時間執行，并且它使得庫的代碼節不可共享。
首先，性能問題。如果以載入時重定位項鏈接一個共享庫，在應用程序載入時，需要花費一些時間執行這些重定位。你可能會認為這個代價不會太大——畢竟，載入器不需要掃描整個代碼節——它僅需考慮重定位項。但如果一段復雜的軟件在啟動時載入多個大的共享庫，而每個共享庫必須首先應用它自己的載入時重定位，這些代價會累積，導致該應用程序啟動時間可觀的延遲。
其次，更為嚴重的不可共享代碼節的問題。首先共享庫存在的要點之一是節省RAM。一些通用的共享庫被多個應用程序所使用。如果共享庫的代碼節（代碼所在）可以只載入內存一次（然后映射到許多進程的虛擬內存），數目可觀的RAM可以被節省下來。但對載入時重定位這是不可能的，因為使用這個技術時，需要在載入時修改代碼節來應用重定位。因此，對于載入這個共享庫的每個應用程序，它將被再次整個地放入RAM[1]。不同的應用程序不能真正地共享它。
另外，擁有一個可寫的代碼節（它必須保持可寫，以允許動態載入器執行重定位）形成了一個安全風險，使得攻擊應用程序更容易。
正如我們將在本文中看到的，PIC極大地緩解了這些問題。
PIC——介紹
?PIC背后的思想是簡單的——對代碼中訪問的所有全局數據與函數添加一層額外的抽象。通過巧妙地利用鏈接與載入過程中的某些工件，使得共享庫的代碼節真正位置無關是可能的，從這個意義來說它可以不做任何改變而容易地映射到不同的內存地址。在下幾節我將詳細解釋如何實現這一壯舉。
關鍵的洞察#1——代碼與數據節間的偏移
PIC所依賴的關鍵的洞察之一是代碼與數據節間的偏移，在鏈接時刻為鏈接器所知。當鏈接器將幾個目標文件合并起來時，它收集它們的節（例如，所有的代碼節合并為一個大的代碼節）。因此，鏈接器知道節的大小與它們的相對位置。
例如，數據節可能緊隨代碼節，因此代碼節中任一給定指令到數據節起始的偏移是該代碼節的大小減去代碼節起始到該指令的偏移——這兩個數據鏈接器都是知道的。
在上圖中，代碼節被載入到某個地址（鏈接時刻未知）0xXXXX000（X表示無關緊要），數據節緊隨其后，在0xXXXXF0000。那么，如果在代碼節0x80偏移處的指令想訪問數據節里的內容，鏈接器知道相對偏移（這個情形里是0xEF80）并將它寫入該指令。
注意到是否有另一個節插在代碼節及數據節之間，或者代碼節跟在數據節后，是無關緊要的。因為鏈接器知道所有節的大小并決定何處放置它們，這個洞察成立。
關鍵的洞察#2——使得IP相對偏移在x86上工作
只有我們讓相對偏移工作，上面的討論才有用。但在x86上訪問數據（即在mov指令里）要求絕對地址。因此，我們該怎么辦？
如果我們有一個相對地址而需要的是一個絕對地址，所缺少的是指令指針的值（因為根據定義，相對地址是相對于指令位置的）。在x86上沒有指令可以獲取指令指針的值，但我們可以使用一個簡單的技巧辦到。下面是展示這個技巧的匯編偽代碼：
??? call TMPLABEL
TMPLABEL:
??? pop ebx
這里發生的是：
1.??????CPU執行call TMPLABEL，這使得它將下一條指令（popebx）的地址保存到棧上并跳到這個標記。
2.??????因為標記處的指令是pop ebx，它下一步得到執行。它從棧里向ebx彈出一個值。不過這個值就是指令本身的地址。因此ebx現在實際上包含了指令指針的值。
全局偏移表（GOT）
有鑒于此，我們最終可以達成x86上訪問位置無關代碼的實現。它依靠一個“全局偏移表”或簡稱GOT來完成。
GOT只是一個地址表，位于數據節里。假設在代碼節里某條指令想訪問一個變量。指令不是通過絕對地址直接訪問它（這將要求一個重定位），而是訪問GOT里的一個項。因為GOT在數據節的一個已知位置，這個訪問是相對的且鏈接器已知。而GOT項將包含該變量的絕對地址：
?
在偽匯編代碼里，我們替換了一條絕對取址指令：
; Place the value of the variable in edx
mov edx, [ADDR_OF_VAR]
以帶一個額外間接性的寄存器位移尋址：
; 1. Somehow get the address of the GOT into ebx
lea ebx, ADDR_OF_GOT
?
; 2. Suppose ADDR_OF_VAR is stored at offset 0x10
;??? in the GOT. Then thiswill place ADDR_OF_VAR
;??? into edx.
mov edx, DWORD PTR [ebx + 0x10]
?
; 3. Finally, access the variable and place its
;??? value into edx.
mov edx, DWORD PTR [edx]
這樣，在代碼里通過GOT重定向變量的訪問，我們去掉了一個重定位。不過我們還是要在數據節里創建一個重定位。為什么？因為要讓上面描述的場景工作，GOT仍然必須包含變量的絕對地址。那么我們得到了什么好處？
答案是很多。因為兩個原因（它們直接解決了文章開頭描述的載入時重定位代碼的兩個主要問題），在數據節里的重定位比代碼節里的重定位問題要少得多，
1.??????每次變量訪問都要求代碼節里的重定位，而在GOT里對每個變量我們只需要重定位一次。對變量的訪問數極可能遠多于變量數，因此這更高效。
2.??????數據節是可寫的且不在進程間共享，因此向它添加重定位沒有害處。而將重定位移出代碼節使得代碼節變成只讀且在進程間共享。
帶有通過GOT的數據訪問的PIC——一個例子
現在我將出示一個展示了PIC機制的完整例子：
int myglob =42;
?
intml_func(int a,int b)
{
??? return myglob + a + b;
}
這段代碼將被編譯為一個名為libmlpic_dataonly.so的共享庫（適當地使用-fpic及-shared標記）。
讓我們 看一眼它的匯編，關注ml_func函數：
0000043c <ml_func>:
?43c:?? 55????????????????????? push?? ebp
?43d:?? 89 e5?????????????????? mov??? ebp,esp
?43f:?? e8 16 00 00 00????????? call??45a <__i686.get_pc_thunk.cx>
?444:?? 81 c1 b0 1b 00 00?????? add???ecx,0x1bb0
?44a:?? 8b 81 f0 ff ff ff?????? mov???eax,DWORD PTR [ecx-0x10]
?450:?? 8b 00?????????????????? mov??? eax,DWORD PTR [eax]
?452:?? 03 45 08??????????????? add??? eax,DWORD PTR [ebp+0x8]
?455:?? 03 45 0c??????????????? add??? eax,DWORD PTR [ebp+0xc]
?458:? ?5d????????????????????? pop??? ebp
?459:?? c3????????????????????? ret
?
0000045a <__i686.get_pc_thunk.cx>:
?45a:?? 8b 0c 24??????????????? mov??? ecx,DWORD PTR [esp]
?45d:?? c3????????????????????? ret
我準備通過它們的地址訪問指令（反匯編代碼里最左側的數字）。這個地址是自該共享庫載入地址的偏移。
·????????在43f，下一條指令的地址放入了ecx，通過上面關鍵的洞察#2所描述的技術。
·????????在444，從該指令到GOT所在位置的一個已知的常量偏移加上ecx。因此現在ecx用作GOT的基址指針。
·????????在44a，從[ecx – 0x10]獲取一個值放入eax，它是一個GOT項。這是myglob的地址。
·????????在450執行間接取址，myglob的值被放入eax。
·????????隨后參數a和b加到myglob，并返回這個值（通過把它保存在eax）。
我們可以以readelf –S查詢該共享庫來看GOT節放在哪里：
Section Headers:
? [Nr] Name???? Type??????????? Addr???? Off???Size?? ES Flg Lk Inf Al
? <snip>
? [19] .got???? PROGBITS??????? 00001fe4 000fe4 000010 04? WA? 0?? 0? 4
? [20] .got.pltPROGBITS??????? 00001ff4 000ff4 00001404? WA?0?? 0? 4
? <snip>
讓我們來檢驗編譯器找出myglob所完成的計算。正如我上面提到的，對__i686.get_pc_thunk.cx的調用將下一條指令的地址放入ecx。那個地址是0x444[2]。下一條指令將它加上0x1bb0，在ecx中的結果將是0x1ff4。最后，為了實際獲取保存myglob地址的GOT項，使用位移地址——[ecx– 0x10]，因此這個項在0x1fe4，它是依據節頭的GOT的第一個項。
為什么有另一個名字以.got開頭的節將在后面解釋[3]。注意編譯器選擇將ecx指向GOT末尾，然后使用負的偏移來獲取項。這沒問題，只要能算出來。而目前為止是可以的。
不過我們還是漏了一些東西。Myglob的地址如何真正地進入到0x1fe4處的GOT槽？記得我提到過一個重定位，因此讓我們找找看：
> readelf -r libmlpic_dataonly.so
?
Relocation section '.rel.dyn' at offset 0x2dc contains 5entries:
?Offset???? Info???Type??????????? Sym.Value? Sym. Name
00002008? 00000008R_386_RELATIVE
00001fe4? 00000406R_386_GLOB_DAT??? 0000200c?? myglob
<snip>
注意myglob的重定位節正如預期那樣，指向地址0x1fe4。該重定位具有類型R_386_GLOB_DAT，它只是告訴動態載入器——“將這個符號的實際值（即它的地址）放入那個偏移”。因此所有東西都工作得很好。剩下的就是檢查在載入這個庫時，它實際看起來是怎么樣的。為此，我們可以編寫一個簡單的，鏈接了libmlpic_dataonly.so并調用ml_func的“driver”可執行文件，并通過GDB運行它。
> gdb driver
[...] skipping output
(gdb) set environment LD_LIBRARY_PATH=.
(gdb) break ml_func
[...]
(gdb) run
Starting program: [...]pic_tests/driver
?
Breakpoint 1, ml_func (a=1, b=1) at ml_reloc_dataonly.c:5
5???????? return myglob +a + b;
(gdb) set disassembly-flavor intel
(gdb) disas ml_func
Dump of assembler code for function ml_func:
?? 0x0013143c<+0>:?? push?? ebp
?? 0x0013143d<+1>:?? mov??? ebp,esp
?? 0x0013143f<+3>:?? call?? 0x13145a <__i686.get_pc_thunk.cx>
?? 0x00131444 <+8>:?? add???ecx,0x1bb0
=> 0x0013144a <+14>:?mov??? eax,DWORD PTR [ecx-0x10]
?? 0x00131450<+20>:? mov??? eax,DWORD PTR [eax]
?? 0x00131452<+22>:? add??? eax,DWORD PTR [ebp+0x8]
?? 0x00131455<+25>:? add??? eax,DWORD PTR [ebp+0xc]
?? 0x00131458<+28>:? pop ???ebp
?? 0x00131459<+29>:? ret
End of assembler dump.
(gdb) i registers
eax??????????? 0x1??? 1
ecx???????????0x132ff4?????? 1257460
[...] skipping output
調試器進入了ml_func，在IP0x0013144a處停下[4]。我們看到ecx保存著值0x132ff4（它是指令的地址加上0x1bb0，就像前面解釋的那樣）。注意運行時在這里，這些都是絕對地址——共享庫已經被載入到進程的地址空間。
這樣，myglob的GOT項在[ecx –0x10]。讓我們查看一些那里有什么：
?(gdb) x 0x132fe4
0x132fe4:???? 0x0013300c
這樣，我們期望0x0013300c是myglob的地址。讓我們驗證一下：
?(gdb) p &myglob
$1 = (int *) 0x13300c
確實是的！
PIC里的函數調用
好了，這就是在位置無關代碼里數據取址的工作方式。但函數調用又如何呢？理論上，同樣的方法應該也能對付函數調用。不是在call實際包含要調用函數的地址，而是讓它包含一個已知GOT項的地址，并在載入時填充該項。
不過這不是PIC里函數調用的工作方式。實際發生的要更復雜一點。在我解釋如何做之前，要說一下這樣機制的動機。
延遲綁定優化
當一個共享庫訪問某個函數時，該函數的真實地址直到載入時刻才會知道。解析這個地址稱為綁定（binding），它是動態載入器在載入共享庫時完成的。這個綁定過程不簡單，因為載入器必須在特殊的表里查找函數符號[5]。
因此，解析每個函數要花時間。不是很多，但它是累計的，因為庫里函數的數量通常遠多于全局變量的數量。另外，大多數這些解析是無用功，因為通常程序只會調用一小部分函數（想一想各種錯誤處理函數及特殊的條件，它們通常不會被調用）。
這樣，為了加速這個過程，發明了一個聰明的延遲（lazy）綁定方案。“延遲”是計算機編程里一族優化的通用名，其工作被推遲直到它被真正需要的最后一刻，目的是如果在程序的一次特殊運行中不需要其結果，就可以避免執行之。延遲的好例子有寫時拷貝以及延遲求值。
這個延遲綁定方案通過添加另一層的間接性——PLT來實現。
程序鏈接表（PLT）
PLT是可執行文件代碼節的部分，包含了一組入口（每個共享庫調用的外部函數一個）。每個PLT項是一小段可執行代碼。不是直接調用函數，代碼調用PLT里的一個項，它負責調用真正的函數。這個安排有時稱為“彈簧墊（trampoline）”。每個PLT項還在GOT中有一個對應的項，僅在動態載入器解析它時，才包含函數實際偏移。我知道這令人困惑，但希望在下面幾段和圖中解釋了細節后，這會清楚起來。
就像前面章節提到的，PLT允許函數的延遲解析。在共享庫第一次載入時，函數調用還沒解析：
解釋：
·????????在代碼里，函數func被調用。編譯器把它翻譯為對func@plt的調用，它是PLT里的第N個項。
·????????PLT第一個項是特殊的，后跟一堆結構相同的項，每個需要解析的函數人手一個。
·????????除了第一個，每個PLT項包含這些部分：
o??對在對應GOT項里指定位置的跳轉
o??為“解析者”例程準備參數
o??調用解析者例程，它位于PLT的第一項。
·????????第一個PLT項稱為解析者例程，它本身位于動態載入器里[6]。這個例程解析函數的實際地址。稍后會有更多的討論。
·????????在函數的實際地址被解析出來之前，GOT的第N項只是指向jmp后的位置。這就是為什么在圖中這個箭頭的顏色不同——它不是一個實際的跳轉，只是一個指針。
在第一次調用func時會發生這些事情：
·????????調用PLT[n]，并跳轉到由GOT[n]指向的地址。
·????????這個地址本身指向PLT[n]，為解析者準備參數。
·????????調用解析者。
·????????解析者解析func的實際地址，把它的實際地址放入GOT[n]，然后調用func。
在第一次調用后，圖看起來有點不一樣：
注意GOT[n]現在指向實際的func[7]，而不是指回PLT。因此，當func被再次調用時：
·????????調用PLT[n]，并跳轉到GOT[n]指向的地址。
·????????GOT[n]指向func，因此這就將控制權轉給func。
換而言之，現在func將被實際調用，無需通過解析者，代價就是一次額外的跳轉。真的，這就是所有的一切。這個機制允許函數的延遲解析，對于完全沒有被調用的函數根本不解析。
它還使得庫的代碼/數據節完全位置無關，因為唯一使用絕對地址的地方是GOT，GOT位于代碼節并且由動態載入器重定位。甚至PLT本身也是PIC的，因此它可以存在于只讀代碼節里。
我沒有進入解析者的太多細節，但對我們這里的目標它并不重要。解析者只是載入器里執行符號解析的一段低級代碼。在每個PLT項里為它準備參數，連同一個合適的重定位項，輔助它了解需要重定位的符號及要更新的GOT項。
通過PLT及GOT調用函數的PIC——一個例子
再次的，以一個實際的演示強化努力學習的理論，下面是使用上面描述機制解析函數調用的完整例子。這次我會稍微加快一點速度。
下面是共享庫的代碼：
int myglob =42;
?
intml_util_func(int a)
{
??? return a +1;
}
?
intml_func(int a,int b)
{
??? int c = b +ml_util_func(a);
??? myglob += c;
??? return b + myglob;
}
這個代碼將被編譯進libmlpic.so，關注點在從ml_func對ml_util_func的調用。首先讓我們反匯編ml_func：
00000477 <ml_func>:
?477:?? 55????????????????????? push?? ebp
?478:?? 89 e5?????????????????? mov??? ebp,esp
?47a:?? 53????????????????????? push?? ebx
?47b:?? 83 ec 24??????????????? sub??? esp,0x24
?47e:?? e8 e4 ff ff ff????????? call??467 <__i686.get_pc_thunk.bx>
?483:?? 81 c3 71 1b 00 00?????? add???ebx,0x1b71
?489:?? 8b 45 08??????????????? mov??? eax,DWORD PTR [ebp+0x8]
?48c:?? 89 04 24??????????????? mov??? DWORD PTR [esp],eax
?48f:?? e8 0c ff ff ff????????? call??3a0 <ml_util_func@plt>
?<... snip morecode>
有趣的部分是對ml_util_func@plt的調用。注意到GOT的地址在ebx。ml_util_func@plt看起來像這樣（它在一個叫.plt的可執行節里）：
000003a0 <ml_util_func@plt>:
?3a0:?? ff a3 14 00 00 00?????? jmp???DWORD PTR [ebx+0x14]
?3a6:?? 68 10 00 00 00????????? push??0x10
?3ab:?? e9 c0 ff ff ff????????? jmp???370 <_init+0x30>
回憶每個PLT項包含三個部分：
·????????到GOT指定地址的一個跳轉（這是跳轉到[ebx + 0x14]）
·????????為解析者準備參數
·????????調用解析者
解析者（PLT項0）位于地址0x370，但我們這里對它不感興趣。看一下GOT包含了什么更有趣。為此，我們首先做些算術。Ml_func里的“獲取IP”的技巧在地址0x483完成，加上0x1b71。因此GOT的基址在0x1ff4。我們可以使用readelf看一眼GOT的內容[8]：
> readelf -x .got.plt libmlpic.so
?
Hex dump of section '.got.plt':
? 0x00001ff4 241f000000000000 00000000 86030000 $...............
? 0x00002004 96030000a6030000?????????????????? ........
?
ml_util_func@plt著眼的GOT項在偏移+0x14，即0x2008。由上面，該位置上的內存字是0x3a6，它是ml_util_func@plt里push指令的地址。
為了幫助動態載入器完成它的工作，也添加了一個重定位項指定在GOT何處對ml_util_func進行重定位：
> readelf -r libmlpic.so
[...] snip output
?
Relocation section '.rel.plt' at offset 0x328 contains 3entries:
?Offset???? Info???Type??????????? Sym.Value? Sym. Name
00002000? 00000107R_386_JUMP_SLOT?? 00000000?? __cxa_finalize
00002004? 00000207R_386_JUMP_SLOT?? 00000000?? __gmon_start__
00002008? 00000707R_386_JUMP_SLOT?? 0000046c?? ml_util_func
最后一行表示動態載入器應該將符號ml_util+func的值（地址）放入0x2008（回憶這是這個函數的GOT項）。
看這個GOT項在第一個調用后發生的實際修改應該是有趣的。讓我們再次使用GDB。
> gdb driver
[...] skipping output
(gdb) set environment LD_LIBRARY_PATH=.
(gdb) break ml_func
Breakpoint 1 at 0x80483c0
(gdb) run
Starting program: /pic_tests/driver
?
Breakpoint 1, ml_func (a=1, b=1) at ml_main.c:10
10??????? int c = b +ml_util_func(a);
(gdb)
現在我們在第一次調用ml_util_func之前。回憶在代碼里ebx指向GOT。看一下它里面是什么：
?(gdb) i registers ebx
ebx??????????? 0x132ff4
我們所需的到該項的偏移在[ebx + 0x14]:
?(gdb) x/w 0x133008
0x133008:???? 0x001313a6
結尾的0x3a6看起來沒問題。現在，前進到對ml_util_func的調用之后再檢查：
?(gdb) step
ml_util_func (a=1) at ml_main.c:5
5???????? return a + 1;
(gdb) x/w 0x133008
0x133008:???? 0x0013146c
0x133008處的值被改變了。這樣，0x0013146c應該是ml_util_func真正的地址，由動態載入器放在那里：
?(gdb) p &ml_util_func
$1 = (int (*)(int)) 0x13146c <ml_util_func>
正如所期望的。
控制是否及何時由載入器完成重定位
這應該是一個好地方來提及由動態載入器執行的延遲符號解析可以某些環境變量（及在鏈接共享庫時向ld給出的對應標記）來配置。有時這對于特殊的性能要求或調試是有用的。
環境變量LD_BIND_NOW，如果定義了，告訴動態載入器總是在啟動時刻對所有的符號執行解析，不作延遲。通過設置這個環境變量并以GDB重新運行之前的例子，你可以容易地驗證這個行為。你將看到ml_util_func的GOT項即使在該函數的第一次調用前也包含它的真實地址。
相反，環境變量LD_BIND_NOT告訴動態載入器完全不要更新GOT項。外部函數的每次調用都將通過動態載入器并重新解析。
動態載入器也可以由其他標記配置。我鼓勵你看一下man ld.so——它包含了一些有趣的信息。
PIC的代價
本文以陳述載入時重定位的問題以及PIC方法如何應付它們開始。但PIC也不是沒有問題的。一個顯而易見的代價是PIC中所有對數據及代碼的外部訪問都要求額外的間接性。即對全局變量的每次訪問，以及對函數的每次調用，都要一次額外的內存載入。在實踐中這個多成問題取決于編譯器，CPU架構及特定的應用程序。
另一個不那么明顯的代價，是PIC的實現增加了寄存器的使用。為了避免太頻繁地定位GOT，讓編譯器生成將其地址保存在一個寄存器（通常是ebx）的代碼是合理的。
但這因為GOT的緣故束縛了一整個寄存器。盡管對于傾向于擁有大量通用寄存器的RISC架構這不是大問題，對像x86這樣只有少量寄存器的架構這構成了一個性能問題。PIC意味著要少一個通用寄存器，它增加了間接的代價，因為現在要進行更多的內存訪問。
結論
本文解釋了什么是位置無關代碼，以及它如何以可共享的只讀代碼節輔助創建共享庫。在選擇PIC及其替代（載入時重定位）時有一些取舍，最終的結果取決于許多因素，比如運行該程序的CPU架構。
也就是說，PIC正變得越來越流行。一些非intel架構，像SPARC64對共享庫強制PIC代碼，而許多其他架構（比如ARM）包括了IP相對取址模型來使得PIC更高效。對x86的后繼者x64架構，這兩點也成立。在將來的文章里我將討論x64上的PIC。
不過本文的關注點不是性能考慮或架構決定。我的目的是解釋，假定使用了PIC，它如何工作。如果這個解釋不夠清晰——請在評論里讓我知道，我將提供更多信息。
?
[1] 除非所有的應用程序將這個共享庫載入相同的虛擬內存地址。但在Linux上通常不會這么做。
[2] 0x444（與其他在這個計算里提到的地址）是相對于共享庫的載入地址，它是未知的，直到一個可執行文件在運行時實際載入它。在這個代碼里這無關緊要，因為它僅應付相對地址。
[3] 精明的讀者可能想知道為什么.got是一個完全獨立的節。我不是在圖里顯示它在數據節嗎？在實踐中，它是。這里我不想深入ELF節與段的差異，因為這會離題太遠。簡要言之，一個庫可以定義任意數量的“數據”節并映射到一個可讀寫段。只要ELF文件組織正確，這不重要。將數據段分離到不同的邏輯節提供了模塊化，并使得鏈接器的工作變得簡單。
[4]注意gdb跳過了向ecx賦值的部分。這是因為它差不多被視為函數的prolog（真正的原因當然是gcc組織調試信息的方式）。在函數里對全局數據與函數進行了幾次訪問，一個指向GOT的寄存器就可以服務所有這些訪問。
| [5] ELF共享庫對象帶有用于這個目的的特殊的哈希表節。 |
?
[6] 在Linux上的動態載入器只是另一個載入所有運行進程地址空間的共享庫。
[7] 我將func放入一個獨立的代碼節，雖然理論上這可以與調用func代碼在同一個節（即在同一個共享庫）。這篇文章里“extra credit（額外的學分）一節解釋了為什么在同一個共享庫里調用一個外部函數還需要PIC（或重定位）。
[8] 回憶在數據訪問例子里我承諾解釋為什么在目標文件里有兩個GOT節：.got與.got.plt。現在應該明顯了，這只是為了將全局數據要求的GOT項與PLT要求的GOT項方便地分開。這也是為什么當在函數里計算GOT偏移時，它指向緊跟.got的.got.plt。這樣，負偏移引向.got，而正偏移引向.got.plt。盡管方便，這樣的安排不是強制的。這兩部分都可以放在一個.got節里。
總結
以上是生活随笔為你收集整理的共享库中的位置无关代码（PIC）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： STM32F103 SPI 主机模式分析
- 下一篇： C++又一坑:动态链接库中的全局变量