本文簡單對比一下strace和ltrace的使用和輸出信息。
首先編寫一個簡單的socket服務端和客戶端，服務端用父進程來監聽listenfd，將請求connfd交給fork出的子進程來處理，主要代碼如下：
客戶端主要代碼如下：
strace和truss用來跟蹤一個進程的系統調用或信號產生的情況，strace -f -o server.strace ./echoserver得到的服務端strace跟蹤文件如下，除了socket相關的庫函數（應用編程接口API）以外，還有其他很多系統調用以及SIGCHLD和SIGINT信號：
strace輸出文件中，每一行都是一條系統調用，等號左邊是系統調用的函數名及其參數，右邊是該調用的返回值。truss、strace和ltrace的工作原理大同小異，都是使用ptrace系統調用來跟蹤調試運行中的進程。
strace的trace日誌分析：
1）每個item的格式爲：進程號 系統調用（參數列表） = 返回值
2）文件描述符號：0是標準輸入，1是標準輸出，服務器端的3號是listenfd，4是接收到的第一個client的connfd。
而ltrace跟蹤同樣的程序，輸出的信息則相對比較簡單，只有庫函數API和信號：
ltrace日誌分析：
1）每個item的格式：進程號 庫函數（參數列表） = 返回值
2）對比strace發現，應用程序調用stdio庫的printf時，產生的系統調用fstat，mmap，write，最後是由write系統調用將字符串輸出到標準輸出。
3）應用程序調用庫函數fork()來創建一個子進程，對應的系統調用時clone()，在strace中跟蹤到的只有系統調用clone()。
庫函數和系統調用的關係如下圖：
對兩種trace的額外開銷做簡單的分析：
在server端向client端發送消息的前後打上時間戳，即在write前後用gettimeofday記錄開始時間和結束時間，timeval可以精確到微秒，比較不使用trace和使用trace的延時：
不輸出到文件，直接在控制檯輸出的延時比輸出到文件中略微低10微秒：
ltrace的開銷要更大：
不輸出到文件的延遲差不多也是200+微秒。