軟體學徒forever

memory poo l是實現客制化的allocator的常見手法，尤其是對快速的alloc/free有很高要求的環境。之所以可以有較快速的alloc/free，是因為memory pool的特性 - 每個pool中的基本block的大小是一樣的，而alloc時，所要求的memory也都是一個block。 怎麼利用這個特性來實作快速的alloc/free呢？以 Linux kernel為例 ，我們可以看到： 18 static void add_element ( mempool_t * pool , void * element ) 19 { 20 BUG_ON ( pool -> curr_nr >= pool -> min_nr ); 21 pool -> elements [ pool -> curr_nr ++] = element ; 22 } 23 24 static void * remove_element ( mempool_t * pool ) 25 { 26 BUG_ON ( pool -> curr_nr <= 0); 27 return pool -> elements [-- pool -> curr_nr ]; 28 } pool->elments[]是在使用者呼叫 mempool_create(...) 時所動態建立，存放的是一組void *，指向實際可被使用的memory block。當呼叫 mempool_alloc(...) 時，經過一些檢查與處理，就會呼叫到remove_element(...)，回傳指到的memory block的位址，然後將下一次要給出的block位址由pool->curr_nr去索引。很簡單又快速的便完成alloc，free則是類似的反向動作而已。 太簡單了吧？你這麼想著。沒錯，但有人寫出類似如下的實作（當然，是簡化的版本，不過意思到了 :P）： static struct block *remove_element(mempool *pool) { struct block *blk= NULL; ...

這本書的書名很特別，所以一開始就讓我很好奇地拿起來翻閱，講述的內容也較為少見，講的是連結、載入、以及執行期程式庫。 這樣的主題在實用上可能並沒有立即的效果，但對程式設計師而言，這三大主題可看成是我們所撰寫的軟體與作業系統之間的重要轉換過程，瞭解了這個轉換過程，就會更進一步發現系統程式在整體架構上的許多設計考量，這樣的訓練可以幫助在未來想從事系統程式時，提供整體的紮實觀念。 甚至，當我們想撰寫的程式是要跑在裸機上時(像boot loader或作業系統)，完整瞭解這本書中提到的概念，才有可能對如何完成有所了解。 好了，廢話不多說，我來簡單摘要重點章節的內容吧~ Chapter 1 溫故而知新 這章講的是必要的基礎概念，是閱讀此書所必須先俱備一點作業系統的概念，包括：多工、排程、記憶體管理...當然啦，你不需要是作業系統專家就可以閱讀這本書(因為我也不是)，不過如果有過一點kernel programming的實務經驗的話，應該會更能"體會"。:) Chapter 2 編譯和連結 這章講的是C語言如何從原始碼轉變成可執行檔的過程，當然啦，主要的細節會在後續章節補上，但先有個大局觀，的確是不錯的開始。 如果你稍有程式經驗的話，基本上前兩章應該可以毫不費力地讀完，搞不好一杯咖啡還沒喝完就翻完了，不過要注意，從第三章開始就是本書的重點嘍~ Chapter 3 剖析目的檔 在開始講述實際的連結動作之前，作者先從.o檔的格式下手，剖析的標的是Linux 32bit ELF，俗話說的好，要閱讀一份龐大的原始碼時，從它的資料結構下手幾乎會是最好的開頭，剖析目的檔也有類似的現象。目的檔經過多年的經驗累積去調整，有許許多多的欄位塞在裏面，了解重要的幾個欄位，是追蹤時先備的要件。 Chapter 4 靜態連結 靜態連結就是在執行檔被產出的那個moment完成了全部的符號決議與位址計算。沒錯，就是這個moment！！這章講解這個過程如何完成。當完整了解這章後，你應該就完全能理解如何在裸機上寫程式了。酷吧？這是我閱讀這本書的第一個"A Ha"moment~很爽啊~ Chapter 5 Windows PE/COFF 原諒我，我沒有讀這章，因為我實在對M$的環境...

作者： eliben 原文連結： http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/ 共享庫的載入時重定位 這篇文章的目的在解釋現代作業系統如何讓共享庫在載入時的連結動作發生。我們聚焦在32位元的x86 Linux上頭，但相同的原則在其他的作業系統與CPUs上一樣適用。 要注意的是，共享庫有許多不同的名字 - 共享庫（shared libraries）,共享物件（ shared objects）,動態共享物件（ dynamic shared objects (DSOs)）,動態連結庫（ dynamically linked libraries（如果你習慣的是Windows的環境，就知道這是所謂的DLL））。為了一致性，我在整篇文章中會使用"共享庫"這個字眼。 載入可執行檔 如同其他支援虛擬記憶體的作業系統，Linux將可執行檔載入到一個固定的記憶體位址。如果我們檢視任意一個可執行檔的ELF header，我們將可發現一個Entry point的位址： $ readelf -h /usr/bin/uptime ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 [...] some header fields Entry point address: 0x8048470 [...] some header fields 這是由linker所放置的，可告訴作業系統要從何處開始執行此執行檔[1]。如果我們用GDB載入程式並觀察0x8048470的位址，我們將可看到.text segment的第一個被執行的指令。 這代表的是，當linker連結可執行檔時，會把全部的內部符號引用的位址都確定下來（function以及data），確定它們的固定的、最終的位址。Linker本身會對自己進行一些relocation[2]，但最終的結果不會有任何的relocation。 講啥啊？注意，我在上段文中特別強...