想想如果我們自己要做編譯器(compiler)和連接器(linker)，當然希望編譯連接運行得越快越好，同時也希望產生的二進制代碼也是又快又小，上帝是公平的，魚與熊掌不可兼得，所以我們自然想到用兩種build方式，一種Release，編譯慢一些，但是產生的二進制代碼緊湊精悍，一種Debug，編譯運行快，產生的代碼臃腫一點沒關系，Debug版本嘛，就是指望程序員在開發的時候反復的build，為了不浪費程序員的時候，要想盡辦法讓編譯連接速度變快。

假如一個程序有連續兩個 foo 和 bar ( 所謂連續，就是他們編譯連接之后函數體連續存放 ) ， foo 入口位置在 0x0400 ，長度為 0x200 個字節，那么 bar 入口就應該在 0x0600 = 0x0400+0x0200 。程序員在開發的時候總是頻繁的修改 code 然后 build ，假如程序員在 foo 里面增加了一些內容，現在 foo 函數體占 0x300 個字節了， bar 的入口也就只好往后移 0x100 變成了 0x0700 ，這樣就有一個問題，如果 foo 在程序中被調用了 n 次，那么 linker 不得不修改這 n 個函數調用點，雖然 linker 不嫌累，但是 link 時間長了，程序員會覺得不爽。所以 MSVC 在 Debug 版的 build ，不會讓各個函數體之間這么緊湊，每個函數體后都有 padding （全是匯編代碼 int 3 ，作用是引發中斷，這樣因為古怪原因運行到不該運行的 padding 部分，會發生異常），有了這些 padding ，就可以一定程度上緩解上面提到的問題，不過當函數增加內容太多超過 padding ，還是有問題，怎么辦呢？ MSVC 在 Debug build 中用上了 Incremental Link Table ， ILT 其實就是一串 jmp 語句，每個 jmp 語句對應一個函數， jmp 的目的地就是函數的入口點，和沒有 ILT 的區別是，現在對函數的調用不是直接 call 到函數入口點了，而是 call 到 ILT 中對應的位置，而這個位置上什么也不做，直接 jmp 到函數中去。這樣的好處是，當一個函數入口地址改變時，只要修改 ILT 中對應值就搞定了，用不著修改每一個調用位置，用一個冗余的 ITL 把時間復雜度從 O(n) 將為 O(1) ，值得，當然 Debug 版的二進制文件會稍大稍慢， Release 版不會用上 ILT 。

總結

以上是生活随笔為你收集整理的什么是Incremental Link Table[转]的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。