本文轉(zhuǎn)自公眾號，歡迎關(guān)注

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

前言

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

過程

現(xiàn)象是程序運行時進(jìn)入了異常中斷,如下

使用bt回溯可以看到進(jìn)入了異常處理函數(shù)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)

那么首先想到的是確認(rèn)異常原因

查看異常寄存器:info reg mcause

可以看到異常原因是0x07

對應(yīng)的是Store/AMO access fault 異常,這是一個寫數(shù)據(jù)時的異常.

那么接下來就要確認(rèn)寫哪個地方的數(shù)據(jù)錯誤了呢?

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

寫0x28382ad0時產(chǎn)生了異常.

那么什么時候?qū)戇@個地址導(dǎo)致了異常呢，之前bt已經(jīng)看不到回溯的地方了。

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

設(shè)置數(shù)據(jù)斷點 watch (unsigned int )0x28382ad0

重新加載程序運行 load

c運行

看到斷點停在了memset函數(shù)處，這印證了我們前面分析的是寫數(shù)據(jù)導(dǎo)致的問題

繼續(xù)bt查看

我們找到對應(yīng)的代碼處

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

最終確認(rèn)確實是棧初始化時寫0x28382ad0這個地址的內(nèi)容錯誤，原因是不具備寫屬性導(dǎo)致異常

(gdb) p pxStack


$8 = (StackType_t *) 0x28382ad0


(gdb)

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

總結(jié)

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

審核編輯：湯梓紅