注册表值调试

我有一个碰撞方法的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

谢谢。只是混淆了如何进一步处理这个不好的地址。我粘贴的上述内容是内核日志缓冲区内核恐慌无法在虚拟地址处理内核分页请求而这种情况再也没有发生过。有这种罕见的发生机会是什么？ –

回答