本文轉自公眾號，歡迎關注

RISC-V的Store AMO access fault調試實例 (qq.com)

前言

本文以一個實例分享RISC-V的Store AMO access fault異常的調試過程。Store AMO access fault主要發(fā)生在非法地址訪問時(棧溢出,指針異常等)。

過程

現象是程序運行時進入了異常中斷,如下

使用bt回溯可以看到進入了異常處理函數exception ()

(gdb) bt


......


#6 0x02002eb2 in exception () at src/lib/riscv/src/exception.c:55


#7 0x00000000 in ?? ()


Backtrace stopped: frame did not save the PC


(gdb)

那么首先想到的是確認異常原因

查看異常寄存器:info reg mcause

可以看到異常原因是0x07

對應的是Store/AMO access fault 異常,這是一個寫數據時的異常.

那么接下來就要確認寫哪個地方的數據錯誤了呢?

我們可以通過info reg mtval 查看mtval寄存器看到。

寫0x28382ad0時產生了異常.

那么什么時候寫這個地址導致了異常呢，之前bt已經看不到回溯的地方了。

我們可以使用數據斷點來監(jiān)控

設置數據斷點 watch (unsigned int )0x28382ad0

重新加載程序運行 load

c運行

看到斷點停在了memset函數處，這印證了我們前面分析的是寫數據導致的問題

繼續(xù)bt查看

我們找到對應的代碼處

看下memset的參數，如果看不到可以在memset前打斷點重新運行

最終確認確實是棧初始化時寫0x28382ad0這個地址的內容錯誤，原因是不具備寫屬性導致異常

(gdb) p pxStack


$8 = (StackType_t *) 0x28382ad0


(gdb)

當然為什么這個地址不能寫和這里沒關系了，是另外一回事了，是我們的環(huán)境DDR的問題。

總結

以上是一個分析實例的過程,遇到類似問題可以參考。有幾個關鍵點一是確認異常原因,異常訪問的地址,然后通過數據斷點確認什么時候訪問了這個地址，到此基本就確認問題了，后面就順藤摸瓜了。

審核編輯：湯梓紅