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

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

前言

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

過程

現(xiàn)象是程序運(yùn)行時(shí)進(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 異常,這是一個(gè)寫數(shù)據(jù)時(shí)的異常.

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

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

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

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

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

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

重新加載程序運(yùn)行 load

c運(yùn)行

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

繼續(xù)bt查看

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

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

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

(gdb) p pxStack


$8 = (StackType_t *) 0x28382ad0


(gdb)

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

總結(jié)

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

審核編輯：湯梓紅