什么是Incremental Link Table[转]
生活随笔
收集整理的這篇文章主要介紹了
什么是Incremental Link Table[转]
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
想想如果我們自己要做編譯器(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[转]的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: CMOS逻辑电路
- 下一篇: 在Windows下使用gcc