軟體學徒forever

原文作者： Eli Bendersky 原文連結： http://eli.thegreenplace.net/2012/08/13/how-statically-linked-programs-run-on-linux/   在這篇文章中，我想要探討當一個靜態連結的程式在 Linux 上執行時會發生什麼事情。靜態連結指的是一個程式執行時不需要額外的共享物件，即使是無所不在的 libc 也不需要。實際上，我們在 Linux 遇到的絕大多數程式並不是靜態連結的，需要一個或多個共享物件才能夠執行。然而，這類程式的執行流程牽涉較多細節，所以我想先說明靜態連結的程式。這可以為理解整體流程打下好的基礎，並允許我用較少的細節去討論主要的機制。我在未來會有另一篇文章來將動態連結的行程講述清楚。 Linux 核心 程式的執行起始於 Linux 核心 中。為了運行一個程式，一個行程會呼叫 exec 系列函式 其中之一。這系列的函式都非常相似，差別只在於傳入的程式的引數與環境變數。這些函數最後都會發出 sys_execve 系統呼叫 至 Linux 核心。 sys_execve 為了新程式的執行作了許多準備。要全部解釋完畢會超出這篇文章的目的 - 一本好的核心內部機制書籍對於理解這類細節會很有幫助[1]。我將會專住在對目前的討論有用的部份。 核心必須從硬碟讀取程式的可執行檔案至記憶體中並準備其執行。核心知道如何處理許多種類的二進位格式並且試著以相應的處理方式開啟檔案（這在 fs/exec.c 的  search_binary_handler 中發生）。不過，我們此處只先對 ELF 感興趣，這個格式的對應動作在函式 load_elf_binary 中（位於 fs/binfmt_elf.c）。 核心讀取程式的 ELF header，然後檢查 PT_INTERP segment 以確認是否有某個解譯器被指定。這邊就是靜態連結與動態連結開始有差異的地方。對於靜態連結的程式來說，沒有 PT_INTERP segment 。也是此篇文章要涵蓋的範圍。 核心接著根據 ELF program header 中的資訊將程式的 segments mapping 進記憶體中。最後，核心會直接修改 IP 暫存器的值為 ELF heade...

Structure and Interpretation of Computer Programs (SICP) 是非常經典的一本程式設計"入門書"。英文的資訊非常多，也有不少針對書中作業的討論（ Eli Bendersky , Scheme Community ）。由於正體中文的資訊不多，所以我想寫一篇 blog 來紀錄目前的閱讀心得，希望對還沒看過這本書的朋友（或翻過但還在觀望）有些幫助。 這本書建構了程式設計中各種設計取捨與手法的一個 mental framework。開發軟體時我們會遇到各式各樣的問題，針對不同實務問題我們有許多的慣用法去解決，但這些慣用法背後的精神卻只存於經驗豐富的老手心中，難以言表，導致一般新手不易感受。這本書講的就是作者在選擇設計手法時的系統化方式與思考轉折。 書中使用的語言是 Scheme ，雖然不是一般主流的語言，但作者刻意這麼選擇是有道理的。Scheme 的基本語法極其簡單，但抽象化的威力強大，可以在短短的幾行程式中轉換其設計典範。不同的設計典範各有其適合範疇，作者藉由實例與練習題讓我們不斷思考為什麼這樣比較好、為什麼那樣比較好、為什麼... OK~如果你好奇書中到底提了哪些資訊，以下是我目前的讀書摘要： 使用 procedure 建構抽象化。第一章講得是基本要素：基本型別與 procedure。千萬不要以為這部份跟其他語言書籍一樣無趣，這章從最基本的四則運算開始，逐漸引進 recursion的概念，而 recursion 的各式手法也逐一討論，並且在讀者熟悉用 recursion 計算簡單的數值問題後，開始將 procedure 當作 first class object ，在 procedure 間傳遞操作，引進更多設計手法。到這章結束後，我發現自己以前根本就沒善用 procedure 的能力（原因之一是常用的 C/C++ 不易用簡單的方式完成 procedure 的任意傳遞與組合）。 使用 data 建構抽象化。第一章將 procedure 與一般 data 的界線弭平了，但很多時候我們需要強化的概念是在操作的對象本身。我們會希望用簡單的方式看待複雜的 data 與其使用方式。第一章的 data 都是基本數值，雖然說電腦看到的都是數值，但對人類來說，想看到的是 picture, p...

Descriptors in Python is an interesting approach to simplifying many difficult design problems. I would like to share one of my application of this useful feature. Consider the following code snippet: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 class MailEvent ( object ): def fire ( self , instance , cls ): print "handling mail event from " + str ( cls . __name__ ) + " " + str ( instance . name ) class LogEvent ( object ): def fire ( self , instance , cls ): print "handling log event from " + str ( cls . __name__ ) + " " + str ( instance . name ) # using inheritance class BaseWorker ( object ): def __init__ ( self , name ): self . name = name self . event_factory = { "mail" : MailEvent (), "log" : LogEvent ()} def event ( self , evt ): if evt in self . event_factory : self ....

There are many different ways to break dependencies when doing unit testing in C++. We can use approaches described in the book , including constructor injection, setter injection, extract and override, and...yes, the factory design pattern. They work well in some cases so that we should know the pros and cons of every tricks above. However, they have some common shortcomings: unnecessary run-time indirection by using inheritance (it is getting worse when critical execution path is on the objects) unnecessary interfaces should be added and used. (those interfaces are merely for unit test convenience, not so meaningful in production code) Those traditional tricks used in unit test are based on common OO features. If we focus on C++, can we solve these two problems by different thinking?  I gave template a try by writing a simple word count program. Before we go on, you can clone it to play. The main class (mwc) is a class template with a template parameter contai...