前不久寫的一個調試器，公司很多模塊使用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交叉編譯）中也是正確的。