macos - OS X 内核 panic 诊断。如何翻译回溯地址

Question

我正在调试导致我的 mac 上发生内核转储的驱动程序。它显示了由一系列地址组成的长回溯:

panic(cpu 6 caller 0xffffff8004dc9986): trying to interlock destroyed mutex  
(0xffffff8049deedb0)
Backtrace (CPU 6), Frame : Return Address
0xffffff93b1c8bb50 : 0xffffff8004ce5307 
0xffffff93b1c8bbd0 : 0xffffff8004dc9986 
0xffffff93b1c8bbe0 : 0xffffff8004d099eb 
0xffffff93b1c8bc20 : 0xffffff7f85604899 
0xffffff93b1c8bc50 : 0xffffff800519776b 
0xffffff93b1c8bc90 : 0xffffff80051f336c 
0xffffff93b1c8be00 : 0xffffff8005205fb3 
0xffffff93b1c8bef0 : 0xffffff80052028a6 
0xffffff93b1c8bf60 : 0xffffff800522afd1 
0xffffff93b1c8bfb0 : 0xffffff8004df4b16 

我假设由于计算机重新启动，地址转换现在没有用，因为每次启动迭代后内存映射可能不同。

回想一下，有没有什么选项可以将相关方法与每个地址匹配，或者提前设置适当的配置？
谢谢

Answer 1

是的，您绝对可以用符号表示内核 panic 跟踪，但是要追溯进行，您需要来自 panic 日志的更多信息，而不仅仅是原始堆栈跟踪。正如您所说，地址仅相对于加载地址有意义。

Apple 关于该主题的官方文档，TN2063有点过时了。它给出的示例来自 Darwin 9，即 OS X 10.5，从那时起，随着内核 ASLR 和 kext UUID 的引入，情况发生了一些变化。我会尽量给你一个非常快速的最新指南。

1.简单的方法

如果您的 panic 是可重现的，那么最简单的方法就是让内核为您对其进行符号化。使用内核引导参数 keepsyms=1意味着内核不会丢弃存储在内核和 kext 镜像中的任何符号，并且会在发生紧急情况时在堆栈跟踪中查找返回指针。

只需添加 keepsyms=1到 /Library/Preferences/SystemConfiguration/com.apple.Boot.plist 中的内核标志设置，或到 boot-args NVRAM 变量。重新启动，任何后续的 panic 都会被自动符号化。您可以通过 c++filt 运行损坏的 C++ 符号。命令行实用程序来获取正确的 C++ 函数签名。例如，

$ echo __ZN32IOPCIMessagedInterruptController17registerInterruptEP9IOServiceiPvPFvS2_S2_S2_iES2_ | c++filt
IOPCIMessagedInterruptController::registerInterrupt(IOService*, int, void*, void (*)(void*, void*, void*, int), void*)

2.手动方式

如果你有一种没有象征意义的、神秘的 panic ，你似乎无法重现，那么简单的方法没有多大帮助。

在堆栈跟踪之后，立即在紧急日志中查找以“Kernel Extensions in backtrace:”开头的部分。这将列出 panic 中涉及的所有 kext，包括它们的加载地址、版本和 UUID。地址以范围的形式给出；起始地址在 -> 的左边并关注 @ .最后一个地址在箭头的右侧。有了这些信息，您应该能够识别堆栈跟踪中列出的每个代码地址(右侧的十六进制数)所在的 kext。

除了其中一些不会匹配任何 kext。除了在一些奇怪的情况下，这些将来自内核本身。内核镜像(kernel 或 mach_kernel)加载地址位于下方，显示“内核文本库:”

一旦您知道要查看哪个可执行镜像， atos命令将让您符号化每个地址。

例如，假设我们在 panic 中看到这一行:

…
0xffffff8098c1bba0 : 0xffffff7f80c343f2
…

我们还发现:

  Kernel Extensions in backtrace:
     com.apple.iokit.IOPCIFamily(2.9)[BDA92C3B-AD86-33E5-A7F1-1603465350A7]@0xffffff7f80c1a000->0xffffff7f80c4dfff

请注意，0xffffff7f80c343f2 大于(或等于)0xffffff7f80c1a000 且小于(或等于)0xffffff7f80c4dfff，因此有问题的代码在 IOPCIFamily 中。

这使我看到以下命令(及其输出):

$ atos -o /Library/Developer/KDKs/KDK_10.10.5_14F27.kdk/System/Library/Extensions/IOPCIFamily.kext/IOPCIFamily -l 0xffffff7f80c1a000 0xffffff7f80c343f2
IOPCIMessagedInterruptController::registerInterrupt(IOService*, int, void*, void (*)(void*, void*, void*, int), void*) (in IOPCIFamily) (IOPCIMessagedInterruptController.cpp:85)

-o指定可执行文件。这通常在 .kext 包的 Contents/MacOS/子目录中，但一些 Apple 的 kexts 直接在 .kext 目录中。对于内核本身中的函数，提供内核镜像，例如 /Library/Developer/KDKs/KDK_10.10.5_14F27.kdk/System/Library/Kernels/kernel .
-l参数指定加载地址。 IE。开始/文本库。

最后，只需列出您要在该文件中符号化的所有地址。在这种情况下，只有一个，但您可以列出多个。您也可以从 stdin 中读取它们(如果命令行中没有列出)。

有了这个，您应该能够解码整个跟踪。

关于 UUID 的说明

您会注意到跟踪中的每个 kext 以及内核本身都列出了一个 UUID。这有助于确保您使用正确的版本进行符号化。这是来自 Mach-O 二进制文件中 LC_UUID 加载程序命令的 UUID。您可以使用以下方法检查 kext 的 UUID:

$ otool -l /Library/Developer/KDKs/KDK_10.10.5_14F27.kdk/System/Library/Extensions/IOPCIFamily.kext/IOPCIFamily | grep uuid
    uuid BDA92C3B-AD86-33E5-A7F1-1603465350A7

确认用于符号化的 kext 确实与 panic 中的那个相匹配。当您最终遇到奇怪的版本问题，或者如果您遇到 kext 缓存问题时，这非常有用。