1.1. 地址無關代碼

需要被 Prelink 的 ELF 文件，無論是共享庫還是可執(zhí)行文件，編譯時必須加 -fpic/-fPIC 參數(shù)，生成目標無關地址代碼。對于可執(zhí)行文件，不能使用 -fpie/-fPIE 加 –pie 生成地址無關可執(zhí)行文件，否則無法被 prelink。

這個結論是根據(jù)上述測試程序得出的，其中的詳細機理有待進一步研究。

1.2. 檢查Prelink 狀態(tài)

可以使用 readelf 和 objdump 工具來檢查一個 ELF 文件是否已經(jīng)被 prelink。例如：

注意觀察到 6~14 行，對比沒有被 prelink 之前的狀態(tài)，INIT、FINI、STRTAB、SYMTAB 等 section 的地址已經(jīng)修改為運行時進程空間的虛擬內(nèi)存地址。第 30 行，RELACOUNT 表示已經(jīng)預先進行重定位的符號的數(shù)量；第 31 行是 prelink 根據(jù) ELF 所直接依賴的共享庫計算的 MD5 值，該值用于判斷該 ELF 所以來的共享庫是否被修改過；從第 32 行可以看出該 ELF 已被加上 PRELINKED 標記和時間戳。

但是，并非所有被成功 prelink 的 ELF 文件都會加上 PRELINKED 的標記和時間戳。在用 prelink 處理完我們的SDK的后，發(fā)現(xiàn) target_bin 所有的依賴項都有 PRELINKED 標記，target_bin 自身并沒有此標記。但是通過測試其啟動速度，確有巨大的提升，證明 prelink 在 target_bin 上確實發(fā)揮了作用。

至于為什么沒有這個標記，暫時還沒有調(diào)查清楚，仍待進一步研究。

對于上述情況，通過 objdump 等工具查看ELF文件的 section header，我們?nèi)匀豢梢园l(fā)現(xiàn) prelink 處理后留下的蛛絲馬跡。

Prelink 之前，查看 target_bin 的節(jié)頭：

Prelink 之后，再次查看節(jié)頭：

對比 prelink 前后的節(jié)頭信息，我們發(fā)現(xiàn) prelink 后每個節(jié)的地址都有了調(diào)整，增加了.gnu.liblist ， .gnu.conflict 和 .gnu.prelink_undo 這三個節(jié)。同時 .dynstr 節(jié)的 size 由 0xa3cb1 增加到了 0xa3e8c。這些都是 prelink 之后 ELF 的 size 有所增大的原因。

1.3. 查看ELF依賴樹

Prelink 的處理過程是從目標 ELF 文件開始，檢查其依賴樹。從葉子節(jié)點開始處理，自底向上，直至根節(jié)點。若中間任何節(jié)點處理異常，則目標文件都無法被 prelink。同理，如果已經(jīng)被 prelink 處理的 ELF 文件，如果其依賴樹的中任何節(jié)點對應的 ELF 文件有更改，則需要從根開始重新 prelink。如果被更改的 ELF 所處的層級較低，被很多可執(zhí)行文件依賴，則可能整個系統(tǒng)的 ELF 都需要重新進行 Prelink 處理。

可以使用 lddtree 查看 ELF 文件的依賴樹。但是這個工具比較雞肋，只適用于處理本機的 ELF 文件，無法像 prelink 一樣可以在運行時指定 sysroot 和 LD_LIBRARY_PATH。

1.4. 不必要的依賴項

如果 prelink 在處理某個 ELF 文件（記為 A）的過程中，發(fā)現(xiàn) A 并沒有使用其直接依賴的另一個 ELF 文件（記為 B），而 A 又通過 C 間接依賴到 B，并且 B 已經(jīng)被 prelink 處理。此時，A 將無法被 prelink。

1.5. 動態(tài)加載的共享庫

Prelink 對于通過 dlopen 方式打開的共享庫沒有效果。