原文：
http://www.cnitblog.com/textbox/articles/61881.html這些天來弄了一個簡單的驅動模塊，后發現系統只要一卸載模塊系統就會死掉。到底是那里出了錯？
如果你只是通過printk來調試， 而沒有其他的方法去檢測錯誤的。
也是這個原因促使我寫驅動模塊調試技術相關技術。要學好一個編程語言工具首先調試技術也一定同步。
（如果linux 也能做出一個類似windows 下的 Windbg 或
Soft-ICE 那就不必那么麻煩了)
這篇文章不是一氣呵成的，只是我在學習內核調試的一個筆記。
調試技術有以下幾種：
1.用打印調試
2.文件保存調試信息
3.truss、strace和ltrace命令輸出信息來調試
4.調試器來調試
對于第一種 “用打印調試 ”
利用函數或命令把相應的信息輸出到console或文件內
這些函數有 printk , STOCLINUX 等等
prink 的一般用法是定義成一個公用的宏
#undef PDEBUG /* undef it, just in case */
#ifdef SCULL_DEBUG
#ifdef __KERNEL__
/* This one if debugging is on, and kernel space */
#define PDEBUG(fmt, args
) printk( KERN_DEBUG "scull: " fmt, ## args)
#else
/* This one for user space */
#define PDEBUG(fmt, args) fprintf(stderr, fmt, ## args)
#endif
#else
#define PDEBUG(fmt, args) /* not debugging: nothing */
#endif
#undef PDEBUGG
#define PDEBUGG(fmt, args) /* nothing: it's a placeholder */
DEBUG = y
# Add your debugging flag (or not) to CFLAGS
ifeq ($(DEBUG),y)
DEBFLAGS = -O -g -D SCULL_DEBUG # "-O" is needed to expand inlines
else
DEBFLAGS = -O2
endif
CFLAGS += $(DEBFLAGS)
這樣定義的宏可以在內核模式和用戶模式在 Debug 版本下輸出調試信息，而在release版本編譯時候去掉調試輸出的函數代碼。
并可以通過設置makefile就可以是否輸出調試信息，
缺點是修改makefile還需要重新編譯一次。
想法，如果能給模塊一個配置文件 （*.conf）那就修改配置文件就不用重新編譯，只需要卸載安裝模塊就實現調試信息的輸出，
缺點是影響系統的性能。
對於第二種 “文件保存調試信息 ”
內核模式下可以使用 /proc文件系統 或者 seq_file 來記錄調試信息。創建自己的/proc文件系統的文件 或 seq_file 文件 并記錄相應的調試信息，用于查詢。
seq_file 操作可以參考 http://blog.chinaunix.net/u/12313/showart_172686.html；
還有 用ioctl 命令。這些命令可以從驅動模塊拷貝相關的數據結構到用戶空間, 用于查詢它們，缺點是需要用另外的程序來發出和顯示調試信息，并增加模塊的體積 。優點是比/proc塊
oops消息 ，通常消息發生于引用了 NULL 指針或者使用其他不正確指針值。
調試器
使用 gdb
優點：比較適用于用戶模式下調試程序，linux自帶無需重新安裝
缺點：不適合內核模塊的調試（也可以內核調試，利用它的遠程調試功能。需要兩臺電腦）
主要步驟是
1.執行 #gdb program
2.執行到mian():#start
3.設置斷點
4.調試
具體命令使用： 參考 http://baike.baidu.com/view/639266.htm
使用kdb
優點：不需要遠程調試
缺點：不支持源代碼級別上的調試只能使用匯編級別的調試,需要重新下載安裝包,安裝需要重新編譯內核激活kdb
使用 kgdb
優點：可以對內核進行全方面的調試 （感覺有點類似 windows 下的WinDdg)
缺點：需要兩臺電腦，配置復雜 ，更新慢，到目前位置最高只能支持2.6.15.5 版本的內核
使用Linux Trace Toolkit
使用Dynamic Probes ( DProbes )
使用
SkyEye 優點：
ARM Simulator很好地結合在了一起 主要用于嵌入式驅動開發領域 缺點：配置文件設置復雜
使用 UML （虛擬機類似）
優點：
UML適合于調試那些處理與硬件無關的驅動程序缺點：
UML并不適合于調試那些處理實際硬件的驅動程序使用
JTAG- based debuggers優點：
The JTAG (Joint Test Action Group) based debuggers are hardware assisted and powerful tools缺點：
but are expensive.