註冊表值調試

我有一個碰撞方法的objdump。我發現崩潰是由於內存訪問不正確。存儲器地址存在於MIPS寄存器a0中。有沒有一種方法可以跟蹤註冊器如何獲得這個地址，而不是逐步回溯（漫遊）objdump（a0從s3等得到它）。註冊表值調試

我還有一個問題。

在內核中如何進行分頁。內核中的虛擬地址一定沒有概念，因爲它們都已經在內存中。我在崩潰後得到的這個問題有一個叫做BADVA的東西（它是不是虛擬地址），它包含一個不好的地址。

這裏是崩潰報告

Cpu 0 
Registries dump 
Status: 10000302 KERNEL EXL 
**Cause : 00803c08 TLBL** 
**BadVA : fdca9b68** 
PrId : 01019378

你的意思是在拆卸意義上的「objdump」？一般來說，正確的工具是像gdb這樣的調試器。除非崩潰代碼是用匯編語言編寫的，否則應該查看C源代碼級別而不是原始寄存器。這就是調試器的用途。 –

是的。它是一個拆卸。這是一次性崩潰，再也沒有發生過。我需要檢查地址是否從用戶空間傳遞。 –

好的，我錯過了這是在內核中。這使得使用調試器變得非常困難，但仍然不是不可能的（谷歌'kgdb'）。但是你應該在你的內核日誌中有一個OOPS報告來幫助你進行分析 - 一般來說，查看堆棧跟蹤和破壞發生的原因要比單獨從一個壞地址開始並且通過工作更容易拆卸。 –

墜毀的直接原因是，沒有TLB條目BadVA虛擬地址相匹配，而這發生在CPU處於異常模式。

BadVA地址（fdca9b68）位於虛擬地址空間的KSEG2區域。該區域用於MIPS Linux內核中的映射地址（通常用於內核模塊）。我會懷疑內核模塊中的錯誤。

如果您想了解MIPS CPU中發生了什麼，您應該購買和研究See MIPS Run。

2012-08-28 22:39:46 markgz

謝謝。只是混淆瞭如何進一步處理這個不好的地址。我粘貼的上述內容是內核日誌緩衝區內核恐慌無法在虛擬地址處理內核分頁請求而這種情況再也沒有發生過。有這種罕見的發生機會是什麼？ –

回答