内核trace分析工具入门

内核进程 进程堆栈  各个核运行的进程内容。。。。内核分析的维度比较多，所以需要一些工具分析，包括各个soc参商也有自己的工具，当然他们的分析软件需要有账号

内核问题处理的经验也是通过解析了几百个？dump，分析过各种crash panic 橙屏问题积攒出来的

在计算机科学中，符号表是一种用于语言翻译器（例如编译器和解释器）中的数据结构。在符号表中，程序源代码中的每个标识符都和它的声明或使用信息绑定在一起，比如其数据类型、作用域以及内存地址。所以解dump（简单说就是各种函数数据结构及进程信息都有）时候需要符号表（这个dump要对应这个软件版本的符号表，毕竟不同软件版本的函数变量都是不一样的），才能定位最后carsh在了那个位置，现场的相关函数和数据结构都是哪些，以及相应的进程信息堆栈情况。

TRACE32是由德国Lauterbach公司研制开发的一款仿真测试工具,好像针对ARM及其他架构都可以。不局限于某个芯片平台，也不局限于某个芯片厂商。

Linux中将进程称为"task"，是因为在Linux中，进程不仅仅是一个程序在执行，还包括了该程序所需的资源，如内存、文件、网络连接等。因此，"task"这个词更加全面地描述了进程在Linux中的本质。

工具只需要T32软件，通过软件的协助，恢复crash时现场，帮助debug crash原因。这个是我们最常见的使用方式

Crash tool

crash 是一个用于分析内核转储文件的工具，一般和 kdump 搭配使用。命令行工具。
使用 crash 时，要求调试内核 vmlinux 在编译时带有 -g 选项，即带有调试信息。Crash 工具 是在 GDB 的基础之上进一步开发的，所以 Crash 工具的很多命令在 gdb 上应该都是可以直接使用的，本篇文档主要介绍如何使用 Crash 来分析panic/hang 类型的一些 bug，这里需要注意的是有些 bug，如 hang，只能使用 etb 工具来查看最后各个 cpu 都在干什么。
 

t32常用命令

打call trace    v.f /task 0xFFFFFF88E5CEDDC0

查看变量   v.v

查看内存    d.dump 

查看cmdline       v.v saved_command_line

T32实例（解dump 输出卡死函数及位置）

以某高通平台为例，T32可以理解为通过符号表（知道了具体函数变量位置粗暴理解）来集中展示dump信息（比如所有进程出入栈信息，具体汇编操作，各个芯片核的运行情况等等   太多了 不能一以贯之   一次写不完    我边学边写吧）。

除了通用T32这种通用dump解析工具（所谓解析dump我理解就是展示各种信息），芯片平台一般会有自己的工具来解析。这里也会展示高通自己的工具解析样式。

1，芯片厂商解析

qcom自己的工具，通过qpst工具下载dump，再下载对应的符号表，通过qcap解析输出到浏览器。

解析界面

解析结果

2,用T32看dump解析

抓到dump文件，其中out是解析后才有

符号表elf文件

用T32看dump解析

搞错了

有了有了，原来是T32有些问题，本地解析还没弄好，再说吧再说吧

这样就可以捣鼓各种trace，task（进程），栈调用，定位，stack（栈）

T32解析需要什么

dump及对应符号表    这是原材料

解析指令

python xxx\ramparse（ramparse路径一个工具如下）.py -v <vmlinux_path> --force-hardware <项目名称> -x -a <dump路径dir> -o <output_path> --mod_path <all_load_mod_symbol_path符号表路径>

这里我把ramparse和dump ms（符号表）放到了一起

解析错误，尴尬，爱错错去吧，不看了。话说vmlinux_path这个玩意干啥用的

需要用到python

T32工具（不用安装，其实只是用来看结果的），crashman（相当于对应该款芯片的文件，我也不清楚）

3，实例分析

直接上dump解析

call trace，空指针来自src2p

1. 通过list确定代码位置

2. addr2非法地址0x8

往上找，灰阴影位置为函数

压栈情况

for循环  cluster第一次的时候

cpumask一级二级指针，这个是指令   v.infocpu_array

结论： lowest_mask 是0xFFFFFF89F177E8F8， 是&cpu_array[order_index][cluster]引入的空指针。cluster = 1， order_index 由于编译器优化，t32没有直接恢复出来

1. 检查cpumask_t __read_mostly **cpu_array 变量

直接v.v，可以先用v.info帮忙分析它是啥

&cpu_array[2][1] 为什么会是0x8，结合上面dump内容看就很清晰了， cpu_array[2]是0 ，一个cpumask的大小是8字节，所以 cpu_array[2] +1 就是0x8

恢复上层寄存器

当gcore无法恢复上层现场时， 通过T32能做点什么？ 比如遇到Init kill 导致的crash，上层echo c 主动触发的panic。

从用户态陷入内核态时，一定会保存用户空间的寄存器，这样从内核态返回时，才能恢复用户态的现场。用户空间的寄存器，会以struct pt_regs结构被保存在内核栈的栈底，内核栈大小固定16K。

从task_struct中获取栈顶 0xFFFFFFC008058000（底地址）， 退到栈底0xFFFFFFC00805C000（高地址）。 通过v.info 查看pt_regs结构体大小为0x150， 所以pt_regs地址就是

0xFFFFFFC00805C000-0x150=0xFFFFFFC00805BEB0

B::v.v (struct pt_regs)0xFFFFFFC00805BEB0 恢复出来用户态寄存器

内核sp pc寄存器

ARM中所有寄存器都是32位的。这里以cortex-a7内核的MX6ULL处理器为例，按照功能可以分为两类：运行需要寄存器（程序正常运行所需要的，比如变量暂存，pc制作等，总共43个），系统管理控制寄存器（存在于协处理器cp15的16个寄存器，用于mmu存储管理控制，cache控制，中断控制，浮点运算单元FPU等功能）。因此cortex-a7内核总的有59个寄存器。

4，一个dump是一个经验，100个就是100个经验

内核问题有的会把机器卡死，表现为冻屏，橙屏

或者系统卡

原因呢？有内存类      非法地址访问（写入只读内存、从不可读取的内存读取、引用空指针、访问受管理程序保护的内存、访问用户空间地址、栈溢出等）

调度类      死锁，互相持锁     Linux在中断处理程序中，如果使用可能睡眠的函数，引起panic、死锁、io error等引起的调度类panic

大部分问题其实定位到core trace就已经定位到位置，从代码逻辑梳理也能大概定位到原因。只不过T32能把具体场景比较详细的还原出来

太粗暴太简陋了。后面再写好些

参考链接：

【ARM Linux 系统稳定性分析入门及渐进 1 -- Crash 工具简介】_linux ramdump-CSDN博客

T32 使用技巧 - 知乎

arm中SP，LR，PC寄存器及处理器运行模式_lr寄存器-CSDN博客