Libraries
ELF 共享庫 - PLT 的動機
可以使用自修改程式碼來加速動態連結庫中的函式呼叫嗎？
據我了解，ELF 共享庫使用一種間接跳轉表（過程連結表，或 PLT）來實現庫函式的惰性綁定。目的似乎是避免不得不修改程式碼段中的表，同時仍然在第一次呼叫時啟用函式位置的延遲解析。
在載入時動態創建該表的程式碼，或者甚至在第一次函式呼叫時動態創建程式碼不是更快嗎？
是否盡可能地在程序之間共享程式碼段（動態表將是程序私有的）？是出於安全原因嗎（可寫程式碼不應該是可執行的——但 JIT 一直都在這樣做，並且載入程序可以在實際啟動程序之前添加和刪除寫權限）？
或者它是這些的組合，並且每個函式呼叫的小性能增益只是不值得付出努力？
我想我們正在談論 x86 架構。
我所知道的大多數基於 UNIX 的作業系統（不僅如此）都在使用self-Modifying Code in protected mode ，因為程式碼段始終是只讀的。載入器無法控制它-它是由核心的記憶體管理子系統處理的。
但是，即使您可以如您所說“在載入時為該表創建程式碼”，它也會違背共享庫的全部目的。這樣，每個程序都會在其地址空間中擁有庫函式的“私有”副本，從而有效地增加其記憶體佔用——創建共享庫的原因之一就是為了解決這個問題。
您描述的整個過程非常複雜，並且比現在使用的 PLT 方法花費更多的處理週期，並且可能會引入更多、新的和有趣的安全問題。