calltrace是什么？
calltrace是内核Oops问题的一部分，它是内核在发生错误时输出的一段调用栈信息，用于帮助开发人员定位问题。calltrace会显示出导致Oops的函数调用链，从而帮助开发人员找到问题的根源。因此calltrace可以帮助开发人员更好地定位和解决内核Oops问题。calltrace一般都是软件导致的问题。calltrace是提醒出现这个问题的风险性，而不是等出现这个问题才报calltrace，所以并不是所有的calltrace都会导致系统挂死。
什么是内核Oops问题？
内核Oops问题是指在Linux内核运行时发生了一个致命错误，可能会导致内核无法继续正常运行，最终系统会崩溃。这种问题通常会在系统运行时出现，而且很难预测和避免。所以可以通过系统打印的calltrace信息帮助解决系统挂掉的问题。导致calltrace的原因有很多，常见的有：踩空指针，访问不存在的地址空间，中断异常等。
有用信息：
有时候calltrace总会报一些有用的信息，例如下图踩空指针的时候会报很明显地能从信息看出来。
还有一个我觉得很有用的信息就是pc指针所指的函数，有时候他会直接指向导致系统挂掉的函数。
下面主要介绍我自己的一个经验分享，定位过程：
1. 找到pc指针所指的函数（由于我遇到的情况不会导致系统挂掉，所以便于定位）
例如：pc: tpm_tis_remove+0x3c/0xc0（0x3c是偏移，0xc0我猜应该是指长度）
2. 在自己的编译服务器重新把驱动编译出来
3. vmlinx（通过这个工具可以找到pc指针所指的函数的地址）
nm tpm_tis_spi.ko | grep tpm_tis_remove(pc指针所指的函数，并保证这个接口在这个驱动的源码里)
例如：0000000002f0 tpm_tis_remove（2f0就是这个函数的符号的地址）
4. objdump（把驱动跟代码关联起来，这里需要注意的是驱动一定要是从你的代码仓编译出，不然地址可能会对应不上）
objdump -DS tpm_tis_spi.ko > tpm_tis_spi.dis
5. 实际符号地址：第三步算出来的地址 0x2f0＋pc指针后面偏移的地址 0x3c
0x2f0＋0x3c = 0x32c
6. vim tpm_tis_spi.dis文件，确认是否能找到该地址
7. addr2line（可以算出在具体到哪个文件哪行代码导致的calltrace，虽然不一定是在那里导致的问题，但是已经足够具体了）
addr2line -r tpm_tis_spi.ko 0x32c（最后的参数就是算出来的实际的符号的地址）
概述：
上面的定位过程只是我之前定位的一个经验总结，也可能有不对的地方，希望对大家有用。有疑问或者有描述不对的地方，可以提出来一起交流。
大家也可以参考下面的链接：
1286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
