用慣了 VC++ 那方便的調試環境, 尤其是VS 2005 debugger 使用起來更讓人得心應手。 在VS 2005 可以很方便的查看變數值, 動態修改記憶體值,堆棧架構, 各種記憶體查看視窗。更方便的是當滑鼠移動到變數立即顯示出變數的地址和該變數值,當該變數是結構體或類獲自訂結構時可以很方便的展開查看。結構體的自動延伸讓我們更快的瞭解目標變數的結構。
我通常每寫完一個下函數或模組就 F5 調試一下,仔細查看各過程變數是否和自己預想的相同. 通過調試可以:
(1) 可以很快地發現程式何處出錯
(2) 出現了什麼錯誤
(3) 動態跟蹤程式的執行,有助於檢查我們在寫代碼之前的邏輯思維是否正確,程式流程是否合理.
(4) 通過堆棧調用架構,可以確定是哪個函數模組出現了錯誤
(5) 更重要是,調試使我們更進一步看清了程式本質,不再出現莫名其妙的錯誤.
(6) 調試是學習組合語言很有效途徑。
(7) 為我們建立了一種有關該語言的記憶體布局模型。使我們瞭解程式運行時記憶體是怎麼佔用,堆棧情況.這樣出現錯誤時我們就清除錯誤出現的根源並可以很快給出解決方案,而不是像有些程式員把錯誤改正了還不知道為什麼隨處改了幾處代碼程式就運行 OK 了.
記得有一次寫一個 Delphi 調用 VC DLL 的項目,忘了是哪個項目。當Delphi 調用 VC提供的DLL後,DLL的匯出函數在執行期間沒有問題,可是在函數退出時卻出錯.(現在看來這 99.99% 是Call Convention 呼叫慣例不同導致的). 可當時他們delphi 的人1個小時都沒有找出為什麼出錯。 實在不行了, 我開始和他們一起找錯,在同時的指導下我開始開啟delphi 的調試器動態跟蹤程式流程。初次看 delphi 的彙編代碼有點頭疼(原來$ 等用於 C/C++ 的 0x, 表示是 16 進位). 我就用了 OD (OllyDbg ) 調試。真是萬幸,OD 可以源碼級調試, 並可以指定彙編代碼的類型. 用 OD 跟蹤了程式的執行流程,發現函數返回後的返回地址出錯,呵呵現在問題根源找到了, VC DLL 中的函數自己把參數退棧但同時delphi 的彙編代碼又一次把參數退棧,難怪會出現返回地址錯誤. 後來我把這個問題和相關的解決方案發到了網上. 整個解決過程不過 10 分鐘.
有的時候自己犯懶,在寫代碼之前不仔細考慮, 寫一點調試一點. 現在我經常和公司新來的畢業大學生說: 即使代碼不會寫, 蒙也要蒙出來。 不管怎麼說一個C /C++ 程式員最基本的技能就是熟練使用調試器。現在我一有空就給他們講調試器的用法包括系統級調試器 windbg ,syser debuger。 softice 早已退出了曆史舞台,也只是給他們提一下曾經威震江湖的 SOFTICE 的輝煌曆史罷了。
在開發驅動時, 調試器更是必不可, 如果連調試器都不熟,奉勸還是去學習 VB 吧。
使用調試器也並不是一件簡單的事情,至少要求你非常熟悉下面幾點:
(1) 清楚瞭解 什麼是堆棧,在程式運行時具體做什麼用
(2) 清楚瞭解 CPU 結構, 知道什麼是寄存器
(3) 清楚瞭解 組合語言, 不要看到彙編代碼就怕怕的
(4) 清楚瞭解 進階語言的代碼是怎樣在 CPU 上執行的
(5) 瞭解調試器的實現原理和方法, 以應對調試工具本身的出現的問題,更多時候是為了把調試器作為它用。
(6) 清楚瞭解 可執行檔檔案的 2 進位代碼結構,這樣我們可以把 逆向, 破解 等作為最有趣的休閑娛樂活動
相信上面的幾點不是很困難,即使很困難又怎麼樣,別人是人,你也是人,難道他會你就不會,真沒骨氣!!
有很多人稱是高手,連組合語言都不瞭解你還敢說!!丟人!! 不懂彙編別說你是學 C/C++,更別說是搞底層開發的,因為搞底層開發的弟兄們不能和你一起丟人.