01 總覽

編譯階段

nm 獲取二進制文件包含的符號信息

strings 獲取二進制文件包含的字符串常量

strip 去除二進制文件包含的符號

readelf 顯示目標文件詳細信息

objdump 盡可能反匯編出源代碼

addr2line 根據地址查找代碼行

運行階段

gdb 強大的調試工具

ldd 顯示程序需要使用的動態庫和實際使用的動態庫

strace 跟蹤程序當前的系統調用

ltrace 跟蹤程序當前的庫函數

time 查看程序執行時間、用戶態時間、內核態時間

gprof 顯示用戶態各函數執行時間

valgrind 檢查內存錯誤

mtrace 檢查內存錯誤

其他

proc文件系統

系統日志

02 編譯階段

nm（獲取二進制文件里面包含的符號）

符號：函數、變量

參數：

-C 把C++函數簽名轉為可讀形式

-A 列出符號名的時候同時顯示來自于哪個文件。

-a 列出所有符號（這將會把調試符號也列出來。默認狀態下調試符號不會被列出）

-l 列出符號在源代碼中對應的行號（指定這個參數后，nm將利用調試信息找出文件名以及符號的行號。對于一個已定義符號，將會找出這個符號定義的行號，對于未定義符號,顯示為空）

-n 根據符號的地址來排序（默認是按符號名稱的字母順序排序的）

-u 只列出未定義符號

strings（獲取二進制文件里面的字符串常量）

功能：

獲取二進制文件里面的字符串常量

用途：

比較重要的是檢查KEY泄露

eg：strings | grep '^.{16}$'查找中是否存在一行有16個字符的行，并顯示出來。

選項：

-a 不只是掃描目標文件初始化和裝載段, 而是掃描整個文件。

-f 在顯示字符串之前先顯示文件名。

-n min-len打印至少min-len字符長的字符串.默認的是4。

#strings/lib/tls/libc.so.6|grepGLIBC GLIBC_2.0 GLIBC_2.1 GLIBC_2.1.1 ……

這樣就能看到glibc支持的版本。

strip（去除二進制文件里面包含的符號）

用途：

可執行程序減肥（通常只在已經調試和測試過的生成模塊上，因為不能調試了）

反編譯、反跟蹤

readelf（顯示目標文件詳細信息）

nm 程序可用于列舉符號及其類型和值，但是，要更仔細地研究目標文件中這些命名段的內容，需要使用功能更強大的工具。其中兩種功能強大的工具是objdump和readelf。

readelf工具使用來顯示一個或多個ELF格式文件信息的GNU工具。使用不同的參數可以查看ELF文件不同的的信息。

readelf

-a 顯示所有ELF文件的信息

-h 顯示ELF文件的文件頭

-l 顯示程序頭（program-header）和程序段（segment）和段下面的節

-S 顯示較為詳細的節信息（section）

-s 顯示符號信息，

-n 顯示標識信息（如果有）

-r 顯示重定位信息(如果有)

-u 顯示展開函數信息（如果有）

-d 顯示動態節信息，一般是動態庫的信息

objdump（盡可能反匯編出源代碼）objdump –S

盡可能反匯編出源代碼，尤其當編譯的時候指定了-g參數時，效果比較明顯。

addr2line（根據地址查找代碼行）

當某個進程崩潰時，日志文件（/var/log/messages）中就會給出附加的信息，包括程序終止原因、故障地址，以及包含程序狀態字（PSW）、通用寄存器和訪問寄存器的簡要寄存器轉儲。

eg：Mar 31 1128 l02 kernel: failing address: 0

如果可執行文件包括調試符號（帶-g編譯的），使用addr2line，可以確定哪一行代碼導致了問題。

eg：addr2line –e exe addr

其實gdb也有這個功能，不過addr2line的好處是，很多時候，bug很難重現，我們手上只有一份crash log。這樣就可以利用addr2line找到對應的代碼行，很方便。

注意：

該可執行程序用-g編譯，使之帶調試信息。

如果crash在一個so里面，那addr2line不能直接給出代碼行。

參數：

-a 在顯示函數名或文件行號前顯示地址

-b 指定二進制文件格式

-C 解析C++符號為用戶級的名稱,可指定解析樣式

-e 指定二進制文件

-f 同時顯示函數名稱

-s 僅顯示文件的基本名，而不是完整路徑

-i 展開內聯函數

-j 讀取相對于指定節的偏移而不是絕對地址

-p 每個位置都在一行顯示

03 運行階段

調試程序的常見步驟：

1、確定運行時間主要花在用戶態還是內核態（比較土的一個方法：程序暫時屏蔽daemon()調用，hardcode收到n個請求后exit(0)，time一下程序……）。

2、如果是用戶態，則使用gprof進行性能分析。

3、如果是內核態，則使用strace進行性能分析，另外可以使用其他工具（比如ltrace等）輔助。

ldd（顯示程序需要使用的動態庫和實際使用的動態庫）

#ldd/bin/ls linux-gate.so.1=>(0xbfffe000) librt.so.1=>/lib/librt.so.1(0xb7f0a000) libacl.so.1=>/lib/libacl.so.1(0xb7f04000) libc.so.6=>/lib/libc.so.6(0xb7dc3000) libpthread.so.0=>/lib/libpthread.so.0(0xb7dab000) /lib/ld-linux.so.2(0xb7f1d000) libattr.so.1=>/lib/libattr.so.1(0xb7da6000)

第一欄：需要用什么庫；第二欄：實際用哪個庫文件；第三欄：庫文件裝載地址。

如果缺少動態庫，就會沒有第二欄。

strace（跟蹤當前系統調用）

結果默認輸出到2。

-pattach到一個進程

-c 最后統計各個system call的調用情況

-T 打印system call的調用時間

-t/-tt/-ttt 時間格式

-f/-F 跟蹤由fork/vfork調用所產生的子進程

-o，將strace的輸出定向到file中。

如：strace -f -o ~/

-e expr 指定一個表達式，用來控制如何跟蹤，格式如下:

-e open等價于-e trace=open，表示只跟蹤open調用

使用strace –e open ./prg來看程序使用了哪些配置文件或日志文件，很方便。

-e trace=只跟蹤指定的系統調用

例如：-e trace=open,close,rean,write表示只跟蹤這四個系統調用.

-e trace=file只跟蹤有關文件操作的系統調用

-e trace=process只跟蹤有關進程控制的系統調用

-e trace=network跟蹤與網絡有關的所有系統調用

-e strace=signal 跟蹤所有與系統信號有關的系統調用

-e trace=ipc跟蹤所有與進程通訊有關的系統調用

ltrace（跟蹤當前庫函數）

參數和strace很接近

time（查看程序執行時間、用戶態時間、內核態時間）

#timepsaux|grep'hi' 1020218040.00.01888664pts/6S+17:460:00grephi real0m0.009s user0m0.000s sys0m0.004s

注意：

time只跟蹤父進程，所以不能fork

gprof（顯示用戶態各函數執行時間）

gprof原理：

在編譯和鏈接程序的時候（使用 -pg 編譯和鏈接選項），gcc在你應用程序的每個函數中都加入了一個名為mcount（or“_mcount”, or“__mcount”）的函數，也就是說-pg編譯的應用程序里的每一個函數都會調用mcount, 而mcount會在內存中保存一張函數調用圖，并通過函數調用堆棧的形式查找子函數和父函數的地址。這張調用圖也保存了所有與函數相關的調用時間，調用次數等等的所有信息。

使用步驟：

1、使用 -pg 編譯和鏈接應用程序

gcc -pg -o exec exec.c

如果需要庫函數調用情況：

gcc -lc_p -gp -o exec exec.c

2、執行應用程序使之生成供gprof 分析的數據gmon.out

3、使用gprof 程序分析應用程序生成的數據

gprof exec gmon.out > profile.txt

注意：

程序必須通過正常途徑退出（exit()、main返回），kill無效。對后臺常駐程序的調試——我的比較土方法是，屏蔽daemon()調用，程序hardcode收到n個請求后exit(0)。

有時不太準。

只管了用戶態時間消耗，沒有管內核態消耗。

gdb core exec（gdb查看core文件） 準備生成core：

啟動程序前，ulimit -c unlimited，設置core文件不限制大小。（相反，ulimit -c 0，可以阻止生成core文件）

默認在可執行程序的路徑，生成的是名字為core的文件，新的core會覆蓋舊的。

設置core文件名字：

/proc/sys/kernel/core_uses_pid可以控制產生的core文件的文件名中是否添加pid作為擴展，1為擴展，否則為0。

proc/sys/kernel/core_pattern可以設置格式化的core文件保存位置或文件名，比如原來文件內容是core，可以修改為：

echo "/data/core/core-%e-%p-%t" > core_pattern

以下是參數列表:

%p - insert pid into filename 添加pid

%u - insert current uid into filename 添加當前uid

%g - insert current gid into filename 添加當前gid

%s - insert signal that caused the coredump into the filename 添加導致產生core的信號

%t - insert UNIX time that the coredump occurred into filename 添加core文件生成時的unix時間

%h - insert hostname where the coredump happened into filename 添加主機名

%e - insert coredumping executable name into filename 添加命令名

使用gdb查看core：

gdb

opprofile （查看CPU耗在哪）

常用命令

使用oprofile進行cpu使用情況檢測，需要經過初始化、啟動檢測、導出檢測數據、查看檢測結果等步驟，以下為常用的oprofile命令。

初始化

opcontrol --no-vmlinux : 指示oprofile啟動檢測后，不記錄內核模塊、內核代碼相關統計數據

opcontrol --init : 加載oprofile模塊、oprofile驅動程序

檢測控制

opcontrol --start : 指示oprofile啟動檢測

opcontrol --dump : 指示將oprofile檢測到的數據寫入文件

opcontrol --reset : 清空之前檢測的數據記錄

opcontrol -h : 關閉oprofile進程

查看檢測結果

opreport : 以鏡像(image)的角度顯示檢測結果，進程、動態庫、內核模塊屬于鏡像范疇

opreport -l : 以函數的角度顯示檢測結果

opreport -l test : 以函數的角度，針對test進程顯示檢測結果

opannotate -s test : 以代碼的角度，針對test進程顯示檢測結果

opannotate -s /lib64/libc-2.4.so : 以代碼的角度，針對libc-2.4.so庫顯示檢測結果

linux#opreport CPU:Core2,speed2128.07MHz(estimated)CountedCPU_CLK_UNHALTEDevents(Clockcycleswhennothalted)withaunitmaskof0x00(Unhaltedcorecycles)count100000CPU_CLK_UNHAL T.........|samples|%|------------------------3164571987.6453no-vmlinux436111310.3592libend.so76830.1367libpython2.4.so.1.070460.1253op_test

valgrind（檢查內存錯誤）

使用步驟：

1、官網下載并安裝valgrind。

2、-g編譯的程序都可以使用。

官網的示例代碼test.c

#include voidf(void) { int*x=malloc(10*sizeof(int)); x[10]=0;//problem1:heapblockoverrun }//problem2:memoryleak--xnotfreed intmain(void) { f(); return0; }

編譯程序gcc -Wall -g -o test test.c

3、valgrind啟動程序，屏幕輸出結果。

valgrind --tool=memcheck --leak-check=full ./test

注意：

valgrind只能查找堆內存的訪問錯誤，對棧上的對象和靜態對象沒辦法。

valgrind會影響進程性能，據說可能慢20倍，所以在性能要求高的情況下，只能使用mtrace這種輕量級的工具了（但是mtrace只能識別簡單的內存錯誤）。

如果程序生成的core的堆棧是錯亂的，那么基本上是stackoverflow了。這種情況，可以通過在編譯的時候，加上–fstack-protector-all和-D_FORTIFY_SOURCE=2來檢測。Stack-protector-all會在每個函數里加上堆棧保護的代碼，并在堆棧上留上指紋。（記錄下，沒用過）

因為valgrind 查不了棧和靜態對象的內存訪問越界，這類問題，可以通過使用gcc的-fmudflap –lmudflap來檢測。（記錄下，沒用過）

全局變量的類型不一致的問題，現在還找到比較好的方法，這從另一個方面說明全局對象不是個好的設計，這給調試帶來了麻煩。

mtrace（檢查內存錯誤）

mtrace是glibc內提供的工具，原理很簡單，就是把你程序中malloc()和free()的位置全部下來，最后兩輛配對，沒有配對到的就是memory leak。

使用的步驟如下：

1、代碼中添加mtrace()

#include #include intmain(void) { int*p; inti; #ifdefDEBUG setenv("MALLOC_TRACE","./memleak.log",1); mtrace(); #endif p=(int*)malloc(1000); return0; }

這段代碼malloc了一個空間，卻沒有free掉。我們添加9-12行的mtrace調用。

2、編譯gcc -g -DDEBUG -o test1 test1.c

3、執行./test1，在目錄里會發現./memleak.log。

4、使用mtrace memleak.log查看信息。

#mtracetest1memleak.log -0x0804a008Free3wasneveralloc'd0xb7e31cbe -0x0804a100Free4wasneveralloc'd0xb7ec3e3f -0x0804a120Free5wasneveralloc'd0xb7ec3e47 Memorynotfreed: ----------------- AddressSizeCaller 0x0804a4a80x3e8at/home/illidanliu/test1.c:14

可以看到test1.c沒有對應的free()。

04 其他

proc文件系統

內核的窗口。

proc文件系統是一個偽文件系統，它存在內存當中，而不占用外存空間。

用戶和應用程序可以通過proc得到系統的信息，并可以改變內核的某些參數。

proc/目錄結構（部分）：

cmdline 內核命令行

cpuinfo 關于Cpu信息

devices 可以用到的設備（塊設備/字符設備）

filesystems 支持的文件系統

interrupts 中斷的使用

ioports I/O端口的使用

kcore 內核核心映像

kmsg 內核消息

meminfo 內存信息

mounts 加載的文件系統

stat 全面統計狀態表

swaps 對換空間的利用情況

version 內核版本

uptime 系統正常運行時間

net 網絡信息

sys 可寫，可以通過它來訪問或修改內核的參數

proc//目錄結構（部分）：

cmdline 命令行參數

environ 環境變量值

fd 一個包含所有文件描述符的目錄

mem 進程的內存被利用情況

stat 進程狀態

status Process status in human readable form

cwd 當前工作目錄的鏈接

exe Link to the executable of this process

maps 內存映像

statm 進程內存狀態信息

root 鏈接此進程的root目錄

系統日志

/var/log/下的日志文件：

/var/log/messages 整體系統信息，其中也包含系統啟動期間的日志。此外，mail、cron、daemon、kern和auth等內容也記錄在var/log/messages日志中。

/var/log/auth.log 系統授權信息，包括用戶登錄和使用的權限機制等。

/var/log/boot.log 系統啟動時的日志。

/var/log/daemon.log 各種系統后臺守護進程日志信息。

/var/log/lastlog 記錄所有用戶的最近信息。這不是一個ASCII文件，因此需要用lastlog命令查看內容。

/var/log/user.log 記錄所有等級用戶信息的日志。

/var/log/cron 每當cron進程開始一個工作時，就會將相關信息記錄在這個文件中。

/var/log/wtmp或utmp 登錄信息。

/var/log/faillog 用戶登錄失敗信息。此外，錯誤登錄命令也會記錄在本文件中。