0.轉載請保留原創：http://m.shnenglu.com/jinglexy
MSN and Email: jinglexy at yahoo dot com dot cn
前不久寫的一個調試器，公司很多模塊使用linux環境，由于使用平臺的緣故，bug非常多，于是編寫了一個簡單的調試器：大致功能是捕獲程序異常，打印調用棧（也包括調用函數名），對運行的進程進行代碼或函數調試，內核簡單調試等。代碼量并不大，有效代碼行不超過3000行，花了10工作日完成，可能是時間緊迫吧，后期調試用了3周，汗哪！
1．使用ptrace系統調用關聯一個進程后，需要waitpid(pid,
NULL, WUNTRACED);一下，這個調試了很長時間才發現的，我猜測可能是因為ptrace后，不像信號立即 進入目標進程的處理。需要調度到目標進程后，進入do_waitpid()處理函數以設置正確的調試狀態。如果不這樣做，會導致釋放管理進程失敗。比較流行的調試工具gdb就是使用ptrace實現的，在gcc編譯過程中也會插入專門的調試信息。原理比較簡單，實現起來細節需要注意的也很多。
2．在跟蹤程序異常時的調用棧中發現的：montavista編譯環境的一個bug？（不能捕獲動態庫中的異常，主要是因為動態庫加載時地址都不固定，使用了一種叫做got的技術，可以閱讀coly大俠翻譯的《連接器與加載器》一書，非常棒）
當程序收到異常信號后，內核進入do_signal()處理，在arch/arm/kernel/signal.c文件，
do_signal() -- > handle_signal() --> setup_rt_frame()
setup_rt_frame會拷貝上下文環境的數據結構到用戶空間，
就是它的參數 siginfo_t *info,這個數據結構內部包含了上下文的數據結構struct ucontext ,
定義在:include/asm-arm/ucontext.h，內容如下：
struct ucontext {
unsigned long uc_flags;
struct ucontext *uc_link;
stack_t uc_stack;
struct sigcontext uc_mcontext;
sigset_t uc_sigmask; /* mask last for extensibility */
};
在arm_v5t_le-gcc中，上下文結構定義如下：
/opt/montavista/pro/devkit/arm/v5t_le/target/usr/include/sys/ucontext.h文件
typedef struct ucontext
{
unsigned long int uc_flags;
struct ucontext *uc_link;
__sigset_t uc_sigmask;
stack_t uc_stack;
mcontext_t uc_mcontext;
long int uc_filler[5];
} ucontext_t;
在上面數據結構中， __sigset_t
uc_sigmask;被定義在上下文環境之前，
而在內核中 fp指針在 uc_mcontext的arm_fp域中（先將uc_mcontext強制轉換成struct sigcontext結構
在asm-arm/sigcontext.h定義），
也就是第14個 int 成員, 由于上面的stack_t 占內存為3個 int型，所以在nipdebug調試庫中修補為
*bp = ct->uc_sigmask.__val[17];
結論：montavista編譯環境的ucontext.h文件定義上下文環境的數據結構位置不正確，
而該數據結構在/opt/arm/arm-linux/sys-include/sys/ucontext.h（即arm9）中定義是正確的，
/opt/ppc/include/sys/ucontext.h（ppc交叉編譯）中也是正確的。