Android與Linux常用的debug技巧

很久沒有分享心得了
今天來分享一下常用的debug技巧

當系統當機時，最常見的就是stack dump
那要怎麼利用stack dump來track down bug呢
有幾個常見的方法

1.  使用addr2line
這個方法非常好用，但只適用於自己編出來的系統
例如我們在logcat裡看到
07-30 09:52:15.289: INFO/DEBUG(28):          #00  pc 0000aea4  /system/lib/libc.so
07-30 09:52:15.289: INFO/DEBUG(28):          #01  pc 00026810  /data/data/oms.cj.yap/lib/libsdl.so
由logcat我們可以知道
這個當機發生在libc 的0xaea4行
但對應source code在哪裡呢？
這時候就可以
$ addr2line -f -e libc.so 0000aea4
<格式>
$ addr2line -f -e <path to library> <offset>

2. 直接看assembly code
那要怎麼知道哪個symbol是位於哪個library
第一個方法當然就是直接去看makefile
看library究竟包了哪些source file
但這個方法稍嫌麻煩了一點
我們可以利用nm來把symbol從library dump出來
<格式>
$ nm <library>
然後可以用objdump把source code + assembly code 用mixed format輸出
<格式>
$ objdump -dRS <path to library> > tmp

3. 除了addr2line之外，Android ndk tool也有一些很棒的工具可以使用
例如
$ adb logcat |  ndk-stack -sym <path to libraries>
$ ndk-stack -sym <path to libraries> -dump <file with crash log>

再來介紹一下gdb/gdbserver常見的技巧
在embedded system上
我們常常利用gdbserver和gdb配對進行debug
這是因為在embedded system上，通常記憶體,儲存空間,和cpu效率都是有限的
如果我們直接把gdb放到embedded system上會有幾個問題
1. 要使用gdb的話library必須要unstripped, 也就是說我們將會佔用大量的儲存空間
2. 執行gdb會耗費大量的cpu resource, 如果發生的bug與timing有關, 就會比較難以復現, 甚至於會出現其他的問題
另外gdbserver由於體積小所以更有著容易porting的好處

要開始debug時
我們先在embedded system上把gdbserver打開
# gdbserver :5039 <app>

然後在host上執行gdb
arm-linux-gdb
(gdb) target remote 192.168.0.100:5039 # 這個命令指定target的ip
(gdb) info shared # 這個命令用來確定gdb是否正確找到library的路徑, 因為使用cross compilation的關係, 所以通常default search path是不能使用的
(gdb) set solib-search-path staging/usr/lib # 用這個命令來指定library search path
(gdb) set sysroot staging # 也可以用這個命令直接指定cross compilation的root，就不用單獨指定search path了
(gdb) set logging overwrite on # 下面這幾個命令是用來把core dump儲存起來
(gdb) set logging on
(gdb) continue
(gdb) bt full
(gdb) set logging off