推 SILee:GDB直接下info stack就可以直接看到這些資訊了 11/14 22:08
推 zhim:不能用handler直接回報誰觸發的嗎? 12/05 00:44
在我們的系統(ARM)裡, 存取記憶體位址 0~4k 的位置
CPU 會賞一個 memory access exception 給你
這個機制用到了 CPU 的 MMU, 把某個記憶體區段設成 invalid (0~4k)
Exception 觸發以後, 進入 interrupt
只要把 interrupt handler 設定成無窮迴圈, CPU 就死在那裡
所以現在 CPU 埋了這個地雷了, 程式設計師的任務是:
在踩到地雷時, 找出在哪裡出事
----
運氣好的時候, 出事的位置看得到 source code
只要看看 Link Register 附近的程式碼, 就知道位置了
運氣不好的時候, 出事的位置是 library, 比如 memcpy() 這樣的函數
這個 case 要定位, 需要一點技巧...
----
呼叫函數的時候, 會把 Return address 和參數陸續堆到 stack 之上
debug 的概念很簡單, 順著 stack 往"上"找
ps. 看系統, stack 是往記憶體低的地方找, 就是往記憶體位址高的地方找
每個數值都去記憶體看看, 用 dis-assembler 看看對應的指令, symbol
我的經驗是挖個幾層, 通常就有結果了 :D
找到出事的地方, 再順著指令, 找找 LDR/ STR 這類的指令, 看看是哪個關鍵錯了
之後就能用 C level 處理 bug
----
ps.
我很少用這招, 通常是有人搞爆, 但沒人覺得自己寫錯
真的沒招, 非得找出問題才用
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.160.90.237